Understand authentication policies
You can now see directories for your authentication policies, a local directory and an identity provider directory. When you connect an identity provider to your organization, we create a default authentication policy for each directory.
An authentication policy allows you to specify authentication settings for different sets of users and configurations in your organization. It verifies that users who access your Atlassian organization are who they claim to be.
Authentication policies look like this:
Default policy – We automatically add new members to a default policy in your local or identity provider directory.
Non-billable - Create a non-billable policy when you don’t want to pay for certain users. You can only set a non-billable policy as the default policy in the local directory.
Local directory - Contains members you’re not managing in your identity provider. You invite them or they sign up themselves.
Two-step verification – Require a second step when logging in or make it optional for members.
Third-party login – Allow or block logins from third-party accounts.
Password requirements – Track minimum password strength and expiration.
Idle session duration – Track how long members can be inactive before logging them out.
Members – Shows the number of members in a policy. Add or move members from one policy to another policy.
Single sign-on (SSO) – Track when you enforce login to Atlassian through SAML or Google Workspace SSO. You can only enforce SSO in an identity provider directory.
Identity provider directory - Contains members you sync or authenticate through your identity provider. You can add and move members between authentication policies.
Learn more about Authentication policies in this video
When you have an organization with multiple products, you create authentication policies for users within your organization and not for products. If you’d like to give users access to a product, you do that by granting them product access.
Learn about how to edit settings or add members
Authentication policies for Atlassian Government Cloud
An authentication policy allows you set SAML single sign-on for managed accounts, which is a customer responsibility requirement. In an Atlassian Government environment, your authentication policy looks similar to Policy 2 in the illustration above.
From an authentication policy, you see settings for two-step verification, third-party login, and password requirements. However, you are unable to set these options from an authentication policy when you enforce SAML single sign-on. A local directory is also unavailable when you are required to manage all members from your identity provider.
A non-billable policy isn’t available in Atlassian Government environments. This is because don’t have an Atlassian Guard subscription.
Multiple authentication policies
Your organization is up and running with one policy. Flexibility comes from having multiple policies for subsets of users and from being able to test settings before you roll them out to your entire organization.
Your organization needs an Atlassian Guard Standardsubscription or be in the Atlassian Government environment to create more than one authentication policy.
Use cases for authentication policies
To manage your organization, you create multiple policies to address the security of different user sets. You also test settings for subsets of users. When you test settings on a small set of users, you avoid rolling out a policy that may not work for your entire organization.
You can create up to twenty policies for your organization.
Here are some examples of how to use authentication policies for your organization:
Multiple policies for different subsets of users
Your users have different authentication needs. To meet these needs, you create a policy for each subset of users in your organization. This means you create multiple policies.
For example, you can:
Create different policies for specific sets of users such as full-time employees, contractors, the C-Suite, partners
Customize authentication settings for your bot accounts
Create a non-billable policy to control Atlassian Guard Standard subscription costs
Testing your authentication settings
You need to reduce risk and be able to test a configuration setting for a subset of users before rolling it out.
For example, you can:
Test two-step verification on a smaller subset of users to ensure it is set up correctly before rolling it out across your organization.
Test SSO by setting up a different policy for different admin test accounts so you can log in and troubleshoot your policy.
Was this helpful?