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
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 Guard Standard subscription to create more than one authentication policy. Understand Atlassian Guard
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.
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.
To make another policy the default policy:
Go to admin.atlassian.com. Select your organization if you have more than one.
Select Security > Authentication policies.
Select Edit for the policy you want to make the default.
Select Make default policy in the (•••) menu.
To add a policy
Go to admin.atlassian.com. Select your organization if you have more than one.
Select Security > Authentication policies.
Select Add policy.
Select the Directory for your identity provider
Name the policy.
Select Settings you’d like to apply
Select Update policy in the (•••) menu.
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:
Go to admin.atlassian.com. Select your organization if you have more than one.
Select Security > Authentication policies.
Select Edit for the policy you want to delete.
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 Guard Standard subscription.
With an Atlassian Guard Standard 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.
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
Block user API tokens
Add users that you sync from your identity provider 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 bill. Manage your bill for Atlassian Guard Standard.
Make a policy non-billable
To make a policy non-billable:
Go to admin.atlassian.com. Select your organization if you have more than one.
Select Security > Authentication policies.
Select Edit for the policy you want to make non-billable.
Select Make policy non-billable in the (•••) menu
Update a non-billable policy to add all security settings
To update a non-billable policy to all security settings:
Go to admin.atlassian.com. Select your organization if you have more than one.
Select Security > Authentication policies.
Select Edit for the non-billable policy.
Select Add all security settings to policy.
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 Guard Standard 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:
Go to admin.atlassian.com. Select your organization if you have more than one.
Select Security > Identity providers.
Select the Directory you’d like to view.
Select View domains to link the domain to the local directory.
Select Link domain.
Select one or many domains to link to the local directory.
To make a policy non-billable:
Go to admin.atlassian.com. Select your organization if you have more than one.
Select Security > Authentication policies.
Go to the default policy in your local directory.
Select Edit on the default policy.
Select Make policy non-billable.
Was this helpful?