FAQ - Implement SAML single sign-on in Atlassian Cloud apps

I am an organization administrator and after configuring SAML, I can no longer log in.

If some configuration is wrong, this will block any user from the domains to log in again. According to the SAML SSO article, we can see the following recommendations to avoid scenarios like this one:

New incognito window

Because we don't log out your users, use these steps to test SAML configuration while still making adjustments:

1. Open a new incognito window in your browser.

2. Login with an email address from one of your verified domains.

3. Confirm you are signed in correctly and have all the expected access.

Temporary administrator outside of the verified domains

Before configuring SAML single sign-on, create an Atlassian account that you can use to access your organization even if SAML has been misconfigured. This account:

* must not use an email address from domains 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 both site admin and organization admin access.

Consider this account 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.

Use only test accounts to have SSO enforced prior to the rollout

With the Authentication policies feature, you can add specific accounts that will be used to test the SSO implementation on a policy that will have it enforced. This way, if something goes wrong, you can still use the administrator accounts to adjust the configuration.

As an organization administrator, you can also contact Atlassian support via email/voicemail to have the configuration removed or receive an email to bypass SSO and re-configure it.

Will the users be locked out during the process to implement SAML? Also, will they be logged out once it is implemented?

After enabling enforced SSO (SAML), the end users will not be logged out if they are already logged in to their Atlassian account (their Atlassian account session is still active). The end users will be able to continue to access Atlassian Cloud services as normal.

When the end user logs in next, then the end user would be required to authenticate via SAML. If the end user is unable to authenticate via SAML for any reason, then they will not be able to access their Atlassian account.

It is possible to reset end users' Atlassian account sessions by following these instructions: Reset sessions. Doing so will force users to be logged out and log back in via SAML. Please ensure that SAML is working correctly for all users before resetting the end users' Atlassian account sessions.

During the implementation, will there have any downtime?

No. The SAML configuration can be applied at an organization while everyone is working, but, it is highly recommended to do it in offline hours because it is applied as soon as you save it on your Atlassian organization.

If SSO is not configured properly, users will not be able to authenticate once their sessions are expired.

Can I have SAML SSO implemented to users outside of my verified domains?

Please see this document regarding External user security: Understand External user security - it is possible to configure enforced SSO (SAML) for users who are not managed by your organization.

Can I test SSO before enabling it?

The Authentication policies feature allows admins to only include specific (test) users from a verified domain to have security policies enabled. This way, SSO can be tested on specific test accounts before the policy applied to the organization as a whole.

Is SAML restricted to the sites from my organization? Can I have SAML applied only to them?

No. When configuring SAML, it will be applied to the managed accounts from the verified domains and their authentication in https://id.atlassian.com which is used to log-in to any existing Atlassian Cloud sites.

This means that even for sites that are outside of your organization, where the users have access, they will authenticate via SSO because the policy is implemented at an account level instead of a site only.

Can I have multiple SSO configurations at my org?

Per Add identity providers to connect users:

How many you can connect depends on your plan:

* An Atlassian Guard Standard subscription allows you to connect one identity provider. * An Enterprise plan allows you to connect multiple identity providers. Atlassian Guard Standard is included with your Enterprise plan at no extra cost.

Can I have SSO applied to a single product?

No. Due to SAML being implemented to the accounts belonging to the verified domains, the user will go through the SSO authentication for any sites that they have access to.

Can I bypass the managed accounts of my organization from my SSO configuration? For example, a dedicated scope for which users will have it applied.

Yes. With the Authentication policies feature, you can select which users will belong to the security policies configured at the organization.

I have implemented SAML, but, the users are not being asked to authenticate when they access Atlassian sites.

When the SAML configuration is enabled, users will only be asked to authenticate via SAML after they log-out or their Atlassian account session is reset. Even after implementing SAML, if the user still has an active session, the SSO authentication will only be required in the next log-in, even if a different site is accessed.

Also, please check that the end user is in an Authentication policy where "Enforced SSO" is enabled. Documentation: Authentication policy settings for your organizations

Can my users use the local Atlassian account password after SSO is enabled?

No. As soon as SAML is enabled, when the users try to log-in to their Atlassian account, the SAML SSO redirection will be triggered and the end user is redirected to the identity provider(IdP) for authentication.

When a user has enforced SSO enabled and they log in with the third-party account feature: Log in with a third-party account, then the login flow will default back to use the SAML login flow.

At the IDP, the user has multiple email addresses. Which one should I use for the Atlassian account?

When selecting which user attribute in the identity provider(IdP) to map to the NameId claim mapping - ensure that the mapped NameId claim value matches the end user's Atlassian account email. Otherwise:

* If the email is already associated with an existing Atlassian account - the end user will be logged into an unexpected Atlassian account or will receive a "Please try again with a different authentication method." error message * If the email is NOT is already associated with an existing Atlassian account - a new empty Atlassian account will be created for the end user. The end user will not be able to access their products/data until the Atlassian account duplication has been resolved