• Products
  • Documentation
  • Resources

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:

Attributes for authentication policy card
  1. Default policy – We automatically add new members to a default policy in your local or identity provider directory.

  2. 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.

  3. Local directory - Contains members you’re not managing in your identity provider. You invite them or they sign up themselves.

  4. Two-step verification – Require a second step when logging in or make it optional for members.

  5. Password requirements – Track minimum password strength and expiration.

  6. Idle session duration – Track how long members can be inactive before logging them out.

  7. Members – Shows the number of members in a policy. Add or move members from one policy to another policy.

  8. 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.

  9. 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

Atlassian Access for 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.

You need an Atlassian Access subscription to create more than one authentication policy. Learn more about Atlassian Access

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:

A diagram showing default policy for many, Test SSO policy for some, Bot account policy for bots

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 Access 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.

What is a default authentication policy?

Your managed accounts provide you with a pool of users for authentication policies. You assign users to be members of policies. Your organization starts with a default authentication policy. The default policy contains login settings for its members. When you provision new managed accounts, we add them as members to your default policy.

You can now make a default policy a non-billable policy.

To make another policy the default policy:

  1. Go to admin.atlassian.com. Select your organization if you have more than one.

  2. Select Security > Authentication policies.

  3. Select Edit for the policy you want to make the default.

  4. Select Make default policy.

You can’t delete a default policy
1. Select another policy to be the default.
2. Delete the policy (which is no longer the default policy).

To delete a policy:

  1. Go to admin.atlassian.com. Select your organization if you have more than one.

  2. Select Security > Authentication policies.

  3. Select Edit for the policy you want to delete.

  4. Select Delete policy.

What is a non-billable policy?

You can now set default policy as a non-billable policy.

When users are either manually invited or sign themselves up, you can decide whether to include them in your Atlassian Access subscription.

With an Atlassian Access subscription, you can create a non-billable policy when you don’t want to pay for certain users. We won't bill you for users in a non-billable policy. You can only have one (1) non-billable policy.

You can set a default policy into a non-billable policy. You can only create a non-billable policy in a local directory.

Learn more about directories

When you edit authentication policies and make a policy non-billable, you won't be able to:

  • Enforce single sign-on

  • Require two-step verification

  • Add users that you sync from your identity provider (e.g., Okta, Azure AD, G Suite) to the policy

You can't add the users you sync from your identity provider (e.g., Okta, Azure AD, Google Workspace) to a non-billable policy.

If you sync users that are part of a non-billable policy, we move them to a different policy and directory. You can find these users in the default policy of your local directory.

You can easily update your policy to include all security settings. Once you do, the users in the policy may count towards your Atlassian Access bill.

To make a policy non-billable:

  1. Navigate to Authentication Policies at admin.atlassian.com.

  2. Select Edit for the policy you want to make non-billable.

  3. Select Make policy non-billable.

To update a non-billable policy to all security settings:

  1. Navigate to Authentication Policies at admin.atlassian.com.

  2. Select Edit for the non-billable policy.

  3. Select Add all security settings to policy.

  4. Update policy.

To make a default policy non-billable

When you don’t want users who are manually invited or sign themselves up to count towards your Atlassian Access subscription, we can automatically add them to a default non-billable policy.

Before you make a non-billable policy a default policy, you must link the domain for user accounts you want in the local directory. We add new user accounts from the domain you link to the default authentication policy of the local directory.

To link domains to a directory:

  1. Navigate to admin.atlassian.com. Select your organization if you have more than one.

  2. Select Security > Identity providers.

  3. Select the Directory you’d like to view.

  4. Select View domains to link the domain to the local directory.

  5. Select Link domain.

  6. Select one or many domains to link to the local directory.

To make a policy non-billable:

  1. Navigate to Authentication Policies at admin.atlassian.com.

  2. Go to the default policy in your local directory.

  3. Select Edit on the default policy.

  4. Select Make policy non-billable.

 

Additional Help