Learn about security solutions and standards
Care about security? We do too. Learn what Atlassian does and what you can do too.
External user security includes these two types of policies for each organization.
External user policy
Test policy
Who can do this? |
An external user policy allows you to apply security settings to external users. The settings apply to all the external users in your Atlassian organization. It can take a few minutes for the settings to apply to your external users.
If you need single sign-on, you can apply it to users in this policy. Along with the ability to apply single sign-on, you’re able to apply session expiration and to block the usage of user API tokens.
By default, the users in an external user policy count towards your Atlassian Guard Standard bill. Alternatively if you don’t want to use single sign-on you can make your policy non-billable.
How to manage your Atlassian Guard Standard bill
A non-billable policy gives you the flexibility to choose whether or not to include external users in your Atlassian Guard Standard subscription. When you make an external user security policy non-billable, we won’t bill you for users in the non-billable policy.
In a non-billable policy, you’re only able to apply one-time passcode, session duration, user API token access controls.
How to make policy non-billable
A test policy allows you to test external user security settings with a few users before you roll them out to all your external users. You can add up to 5 external users to a test policy. The users don’t count towards your Atlassian Guard Standard bill.
How to set up a test policy
Review the external users in your organization before you apply security settings. You can access their data in two ways:
You can view the number of external users on the external security landing page
You can export external users and their details from a CSV file
By default, external users in your organization can access product data without needing to verify their identity your organization. You can select one these authorization methods to verify their identity: single sign-on and one time-passcode.
You can require users to verify their identity with single sign-on. This means you can manage security for all your users (managed accounts and external users) from one place, your identity provider. This makes it more secure and more efficient.
Before you can apply single sign-on to an external user security policy, you need to:
Connect your identity provider to your Atlassian organization
Configure SAML (Security Assertion Markup Language) for single sign-on
When you connect your identity provider and configure SAML, you can authorize external user access to Atlassian products with single sign-on.
How to authorize single sign-on
You’re unable to connect Google Workspace to apply single sign-on to external users.
One-time passcode allows you to require external users to log in a second time with a one-time passcode. When external users try to access product data in your Atlassian organization, they must verify their identity with a temporary one-time passcode that they receive through their email.
Understand one-time passcode experience for users
In some cases, you may want to allow external users to access your organization without verifying their identity. Select None allows you to do this without requiring external users to log in a second time.
How to edit no authorization method
A session is the amount of time an external user can access products in an organization before they need to verify their identity again. You can choose when a session expires and a user needs to verify their identity. When you set the session length, it only applies to your external users. The setting doesn't apply to managed accounts or mobile sessions.
The session restarts when:
An external user session expires.
You reset sessions for external users.
The external user logs out and logs back in before the session expires.
We recommend letting your external users know about updates you make to session expiration. How to edit session expiration
You’re able to control user API token access to products in your organization with the API token access setting. This setting affects all external users within the organization.
Users create API tokens to authenticate into an organization and to run scripts. API token access controls whether external users can make API product calls with an API token to your organization's products.
By default, your organization's API token settings are set to allow access. You can allow or block access when external users make API calls to your products. This setting applies to all external users in the organization.
API token access updates
It can take up to 10 minutes to update. The update applies the next time an external user tries to make an API call with a token to run a script into your organization. If an external user tries to access your products with a token before the update is done, they can still access the organization.
How to update user API token access
Was this helpful?