Understand authentication policies
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.
Each authentication policy lists key settings that define how users in that policy authenticate when signing in to Atlassian apps.
Default policy – Every organization has at least one default authentication policy that applies to all users unless they’re moved to another policy. What is a default authentication policy?
Billable and 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. What is a non-billable policy?
Members – Shows the number of members in a policy. You can add or move members from one policy to another policy. Edit authentication settings and members
Directory - Lists the user directory (for example, Local or Identity provider directory) that the policy applies to. What are directories?
Two-step verification – Shows whether two-step verification is optional, enforced, or managed by your identity provider.
Single sign-on (SSO) – Indicates whether SSO is enforced through an identity provider. Configure single sign-on for your organization
Third-party login – Indicates whether users can sign in using third-party accounts such as Google or Microsoft. Edit third-party login settings
Password requirements – Shows the required password complexity (for example, Strong) and expiration setting. Manage your password policy
Idle session duration – How long a user session can remain active before the user must sign in again. Update idle session duration
Session expiration - The fixed time limit for user sessions. When the limit is reached, users are automatically signed out, even if they’re still active. Set session expiration
Mobile session expiration - How long mobile app sessions stay active for users in the policy. Set mobile app session expiration
API tokens - Specifies whether members can create new API tokens or use existing ones to authenticate. Configure user API token settings
API token expiration - How long user API tokens remain valid before expiring. Set API token expiration
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.
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. There is no local directory in Atlassian Government environments because you are required to manage all members from your identity provider.
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 non-billable policy isn't available in Atlassian Government environments. This is because the Atlassian Guard subscription is not available in Atlassian Government.
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 Standard subscription, or be in the Atlassian Government environment, to create more than one authentication policy.
When you have an organization with multiple Atlassian apps, you create authentication policies for users within your organization and not for apps. If you’d like to give users access to an app, you do that by granting them app access. Give users access to apps
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 or 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?