Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between parties, in particular an identity provider and a service provider (such as Confluence Cloud).
SAML for single sign-on (SSO) makes it possible for your users to authenticate through your company's identity provider when they log in to Atlassian cloud products. SSO allows a user to authenticate once and then access multiple products during their session, without needing to authenticate with each of those. Note that SSO will only apply to user accounts from your verified domains.
Once your users can log in using SAML single sign-on, they'll still need to be given access to your Atlassian products. See Update product access settings for how to do that.
Note that if you manage users for a site with G Suite, you'll need to use the SSO feature provided by G Suite instead.
Using SAML single sign-on with authentication policies
Authentication policies give you the flexibility to configure multiple security levels for different user sets within your organization. Authentication policies also reduce risk by giving you the ability to test different single sign-on configurations on limited subsets of users before rolling them out to your whole company.
If you configure your security settings with authentication policies, you’ll need to enforce SAML or G Suite SSO within the authentication policy. Visit edit authentication settings and members for how to do it.
Before you begin
There are a couple of things you need to do before you can apply SAML single sign-on to your user's Atlassian accounts:
- Create an organization – see Explore an Atlassian organization.
- Verify one or more domains, to confirm you own those – see Verify a domain for your organization. When you verify a domain, all the Atlassian accounts that use email addresses from the verified domain become managed by your organization.
- Subscribe to Atlassian Access.
Furthermore, we recommend that you check the following:
- Both your Atlassian product and your identity provider should use the HTTPS protocol to communicate with each other, and that the configured product base URL is the HTTPS one.
- SAML authentication requests are only valid for a limited time, so make sure the clock on your identity provider server is synchronized using NTP. If you're using a SaaS identity provider, your clock should already be synchronized.
Before configuring SAML single sign-on, create an Atlassian account that you can use to access your organization even if SAML has been mis-configured. This account:
- must not use an email address from a domain you have verified for this organization. This ensures that the account will not redirect to SAML single sign-on when you log in.
- must be given organization admin access.
Consider this account as temporary: you'll be able to remove admin access from it when you are satisfied that SAML single sign-on is working as expected for your users.
Set up SAML single sign-on
This section describes how to set up SAML single sign-on.
- You need to have already subscribed to Atlassian Access before you can set up SAML single sign-on for your managed users. See Atlassian Access security policies and features for details about how to do that.
Note that during the time it takes to configure SAML single sign-on, users won't be able to log in to your Atlassian cloud products. Consider scheduling a day and time for the changeover to SAML, and alerting your users in advance.
If your identity provider is in the following table, then follow the link to their instructions for setting up SAML single sign-on.
|Identity provider||Set up instructions|
|AD FS||Configure SAML single sign-on with Active Directory Federation Services (AD FS)|
|Microsoft Azure AD|
|Google Cloud||Set up SSO via SAML for Atlassian Cloud|
|Idaptive (formerly Centrify)||Help page|
|Okta||How to Configure SAML 2.0 for Atlassian Cloud|
You'll need to be logged in to OneLogin to see those pages.
If you don't see your identity provider in the table, you can still set up SAML single sign-on with the following steps.
1. Add the Atlassian product to your identity provider
In this step you tell your identity provider which Atlassian products will use SAML single sign-on.
If you use an on-premise identity provider, your users will only be able to authenticate if they have access to the identity provider (for example, from your internal network or a VPN connection).
Make sure that your identity provider can pass an email address value using the NameId attribute. When you add the Atlassian product, add the following SAML attribute mappings to your identity provider:
|SAML attribute name||What it should map to in your identity provider|
|User's first name|
|User's last name|
|Internal Id for the user that will not change.|
Note that this Id should NOT be the user's email address.
For identity provider initiated SAML, enter your organization's URL as the default relay state. Include
https:// as part of your organization's URL.
2. Copy details from your identity provider to your Atlassian organization
- select Security and then SAML single sign-on.
From your organization at admin.atlassian.com,
Click Add SAML configuration.
Copy your identity provider details to these fields:
Field Description Identity provider Entity ID
This value is the URL for the identity provider where your product will accept authentication requests.
Identity provider SSO URL
This value defines the URL your users will be redirected to when logging in.
Public x509 Certificate
This value begins with '-----BEGIN CERTIFICATE-----'.
This certificate contains the public key we'll use to verify that your identity provider has issued all received SAML authentication requests.
- Click Save configuration.
3. Copy details from your Atlassian organization to your identity provider
After adding your identity provider details to the 'SAML single sign-on' page for your Atlassian organization, you'll see new fields and values appear. Copy those values over to your identity provider.
Click Save on your identity provider when you've finished copying everything over.
4. Test SAML single sign-on for your Atlassian organization
Your SAML configuration applies as soon as you click Save on your Atlassian organization. Because we don't log out your users, use these steps to test SAML configuration while still making adjustments:
- Open a new incognito window in your browser.
- Log in with an email address from one of your verified domains.
Confirm you are signed in correctly and have all the expected access.
If you experience a login error, use the Troubleshooting SAML single sign-on section below to make adjustments to your configuration, and test again in your incognito window.
If you're unable to log in successfully, remove the configuration to ensure users can access your Atlassian products.
5. Test SAML single sign-on for subsets of users
Authentication policies give you the flexibility to configure multiple security levels for different user sets within your organization. Authentication policies also reduce risk by giving you the ability to test different single sign-on configurations on subsets of users before rolling them out to your whole company.
You may want to:
Test SSO or two-step verification on a smaller, select group of users to ensure it is set up correctly before rolling it out across your organization.
Troubleshoot your SSO policy by setting up a different policy for different admin accounts so you can log-in and troubleshoot your SSO policy or identity provider integration.
To configure SAML single sign-on from an authentication policy
Navigate to Authentication Policies at admin.atlassian.com.
Select Edit for the policy you want to configure.
When you select SAML SSO you’re redirected from the authentication policy to the SAML SSO configuration page. Learn more about how to configure SAML SSO.
Once you’re done configuring SAML SSO, you need to enable SSO in the policy.
To enforce single sign-on (after you configure SAML SSO):
Navigate to Authentication Policies at admin.atlassian.com.
Select Edit for the policy you want to enforce.
Select Enforce single sign-on.
Just-in-time provisioning with SAML
If self signup is enabled, you don't have to manually create an Atlassian account for the new user. When that user logs in for the first time with SAML, we automatically create an Atlassian account for them.
When new users visit Jira, Confluence, or Bitbucket for the first time:
- They'll enter their email address.
- The login screen for your identity provider appears and they'll enter credentials to authenticate.
- We'll ask them to verify their Atlassian account email address by checking their email.
- They'll click the verification link from their email to log in, which will open the original site (Jira, Confluence, or Bitbucket) they visited.
You can see the multiple cloud sites you have access to, in one place at start.atlassian.com.
Just-in-time provisioning with authentication policies
Every organization has a default authentication policy with login settings for its users. When you provision new accounts, we add new users to your default policy.
For just-in-time provisioning to work with authentication policies, you must enforce SAML single sign-on for a default policy.
If you don’t want to enforce SAML single sign-on for your default policy, you can provision users with SCIM. If you make changes to an email account in your identity provider, we automatically make the changes to the Atlassian account.
If you can’t enforce SAML on your default policy or provision with SCIM, you need to make manual changes.
If you make changes to email in your identity provider, you must manually update the Atlassian account.
If you don’t change the email for the Atlassian account, we create a second account when the user logs in. This user will not have access to any sites or products. To correct this, you can update the email of the original account or delete the account. Update the email of the original account.
Deactivate users with SAML
To prevent a user from retrieving your organization's data via the REST API, deactivate the user in both places – from your organization and from your identity provider.
If you also set up user provisioning for your organization, you only need to deactivate the user from your identity provider.
Reuse email addresses for different users
If a user is no longer using an email address (e.g. they left the company), you can assign that email address to another user. But first, you need to make the email address available for the new account to prevent the new user from getting content for the old account.
To make the email address available:
- From the Managed accounts page, open the account details of the user who no longer needs the email address. If you deleted the account from your identity provider, the account will be deactivated.
- Select Delete account. See Delete a managed account for more details and what happens when you delete an account.
The email address is no longer linked to the deleted user's account and you can assign it to another user.
SAML single sign-on with two-step verification and password policy
When SAML single sign-on is configured, users won't be subject to Atlassian password policy and two-step verification if those are configured for your organization. This means that any password policy and two-step verification is essentially "skipped" during the login process.
We recommend that you use your identity provider's equivalent offering instead.
Remove SAML single sign-on
Before you remove the SAML single sign-on configuration, you should know that your users will need an Atlassian account password to log in.
- Users who had a password on their Atlassian account before SAML single sign-on was enabled will use that to log in.
- Users who joined after SAML single sign-on was enabled will need to reset their password for their Atlassian account when they next log in.
To remove SAML single sign-on:
- select Security and then SAML single sign-on.
From your organization at admin.atlassian.com,
- Now scroll down and click Delete configuration. Confirm the deletion.
We recommend that you also go to your identity provider and remove the SAML configuration for Atlassian there.
Note that removing SAML single sign-on does not unsubscribe you from Atlassian Access. If you no longer wish to enforce security policies on your managed accounts, you can unsubscribe from Atlassian Access.
Troubleshoot your SAML configuration
If you experience errors shown by your identity provider, use the support and tools that your identity provider provides, rather than Atlassian Support.
If users are unable to access your Atlassian cloud products because of the SAML configuration, go to your Atlassian account login screen, click Can't log in? and follow the prompts.
If resetting the password doesn't help, you can troubleshoot from admin.atlassian.com. Before you began configuring SAML, you created an Atlassian account that uses an email address with an unverified domain and made that user an organization admin. Log in with that account to troubleshoot seamlessly because so that you won't have to authenticate with SAML:
- Go to the SAML single sign-on page for your organization to fix or disable SAML sign-on for the rest of your users.
If you're still having trouble, delete the SAML configuration to go back to password authentication with Atlassian account.
If you delete the SAML configuration, you can invalidate all your users' passwords in the password policy screen, which will prompt users to go through the password reset process for an Atlassian account password.
For support tickets being raised, please include the SAMLRequest and SAMLResponse payloads, obtained from the SAML Tracer Firefox add-on. This helps us more quickly identify potential causes of issues.
A plain error screen with no Atlassian branding.
You might have network connectivity issues with your IdP. Try refreshing your page to see if solves the issue.
An error screen for your IdP.
You might have an issue with your identity provider configuration, e.g. a user may not be able to access the Atlassian product from the IdP. Raise a ticket with your IdP to fix the issue.
"Your email address has changed at your Identity Provider. Ask your administrator to make a corresponding change on your Atlassian products."
Known issue with the SAML Beta. You'll soon be able to change the email addresses of your managed accounts from User management.
"We weren't able to log you in, but trying again will probably work."
SAML configuration was disabled for the user during the login process. Verify the SAML configuration and try again.
The identity provider Entity Id in the SAML configuration may be incorrect. Verify that you're using the correct Entity Id and try again.
"xxx is not a valid audience for this Response"
The Service Provider Entity Id in the identity provider SAML configuration may be incorrect. Verify that you're using the correct Entity Id and try again.
"The response was received at xxx instead of xxx"
The Service Provider Assertion Consumer Service URL in the IdP SAML configuration may be incorrect. Verify that you're using the correct URL and try again.
"The authenticated email address we were expecting was 'xxx', but we received 'xxx'. Please ensure they match exactly, including case sensitivity. Contact your administrator to change your email to match."
The user tried to log in to the IdP with an email address different from their Atlassian account email address. Verify that the user is logging in with the correct email address. Email addresses are also case sensitive.
You're most likely using an unsupported IdP. Verify your IdP configuration by making sure you've done the following:
Note that the internal user Id should be a value that will not change. This Id should NOT be the user's email address.
If necessary, you can change the
Frequently Asked Questions
Can I get SAML single sign-on for domains that I cannot verify?
No. To keep products and resources secure, you can only use SAML single sign-on with domains you can verify that you own.
How do I change the user's full name?
You can update the user's Full name by updating First name and Last name in your identity provider's system. The updated name will be synced to your organization when the user next logs in.
Are there any Atlassian cloud products that SAML isn't available for yet?
SAML single sign-on isn't available yet for Statuspage, but we have plans to roll it out later this year.
How does authentication with REST APIs work?
We recommend that your scripts and services use an API token instead of a password for basic authentication with your Atlassian cloud products. Read more about using API tokens.