Atlassian has introduced unique SP Entity ID and ACS URL values: if these are provided to you by Atlassian, you are encouraged to update your current SAML configuration (see Configuring SAML Existing Integrations).
In order to enable SAML single sign-on for Atlassian Cloud products you'll need to set up Atlassian Access. Click here to learn more about Identity Manager.
Atlassian Cloud now supports SCIM, for configuration information, see Atlassian's Configure user provisioning with Okta. If you need further information, contact Atlassian Support at support@atlassian.com.
The Okta/Atlassian Cloud SAML integration currently supports the following features:
For more information on the listed features, visit the Okta Glossary.
You only need to set up SAML once even if you have two different Atlassian Cloud tenants (for example, one for Jira and one for Confluence) as long as your users have the same email address associated to both.
Identify one or more group(s) in Okta which collectively have all your users assigned to your current Jira and Confluence integrations. Because you will be switching to a new integration, identify the groups assigned to your existing Jira and Confluence integrations. It is easier to perform a group app assignment, rather than assigning the new app integration individually.
This section contains the following topics:
You cannot test SAML without interrupting end-users. Before attempting the steps below, please go over the entire flow and plan your migration project accordingly. There will be some downtime for end users, so it is best to schedule a day and time for the migration to SAML, and letting your end-users know in advance.
These are the recommended steps:
Create your organization: If you haven't already, create and name your organization by navigating to: admin.atlassian.com.
Note: You need to be a JIRA, Confluence, or Stride site administrator to access this URL.
Get your domain verified: You need to verify your domain in Atlassian in order to use SAML. Click here to learn more about the domain verification process and managed accounts. Note that you only need to get your domain verified in one tenant, even if you have 2 separate Atlassian Cloud tenants for Jira and Confluence. You will set up SAML in the same tenant in which you verify your domain, and it will work for both tenants if your users have the same email address in both tenants.
Subscribe to Atlassian Access. Read more about Atlassian Access here.
Once your domain is verified one you're subscribed to Atlassian Access, schedule maintenance/downtime and let your end-users know in advance about the migration and that they may not be able to access Jira, Confluence, Stride, or Bitbucket while the migration to SAML is in progress. Then follow steps 3 - 5 of the next section during the scheduled time.
Set up and test SAML: See Enabling SAML for Atlassian Cloud and Testing SAML for Atlassian Cloud for more details.
As a reminder, the domain has to be verified before enabling and testing SAML. If you have two Atlassian sites (for example, https://company1.atlassian.net and https://company2.atlassian.net) linked to the same domain, then you just need to verify the domain once, and both sites would now have a verified domain. This enforces SAML login for both sites even if SAML is not enabled in one or both of the sites.
In Okta, go to the General tab for the Atlassian Cloud app integration, and add both the Jira and Confluence chiclets.
You may want to hide the chiclets for now from end-users to avoid confusion for having duplicate chiclets on their dashboard, until testing is complete. If so, select Do not display application icon to users.
Next, go to the Sign On tab.
Enter your Jira Cloud base URL in the Jira Base URL field. For example, https://[customer-name].atlassian.net
Enter your Confluence Cloud base URL in the Confluence Base URL field. For example, https://[customer-name].atlassian.net/wiki (append /wiki at the end of the URL to land on the Confluence dashboard upon login).
Configure SAML in Atlassian, as described in Configuring SAML for New Integrations.
Assign the Atlassian Cloud app with SAML enabled in Okta to a test user with an email address which is domain verified in Atlassian.
Test IDP flow:
Open a new incognito browser window and go to your Okta organization.
Enter your test user's Okta credentials
Clicking on Jira/Confluence chiclet will log you in to your Jira/Confluence site as your test user.
Test SP flow:
Open a new incognito browser window and go to your Jira/Confluence tenant.
Enter the email address of the test user you set up in Step 3, above.
You will be redirected to Okta; entering the test user's Okta credentials will log you in to your Jira/Confluence site as your test user.
See Troubleshooting SAML section if your testing fails.
Once testing passes, you are ready to switch all your users to start using the new app.
Navigate to admin.atlassian.com.
Note: You need to be a JIRA, Confluence, or Stride site administrator to access this URL.
From your organization, select Security, then SAML single sign-on.
Click Add SAML configuration.
Enter the following:
Identity provider Entity ID:
Sign into the Okta Admin Dashboard to generate this variable.
Identity provider SSO URL:
Sign into the Okta Admin Dashboard to generate this variable.
Public x509-certificate (in PEM text format):
Sign into the Okta Admin Dashboard to generate this variable.
Click Save configuration:
Now you need to copy your Unique ID from Atlassian:
In Okta, select the Sign On tab for the Atlassian Cloud app, then click Edit. Enter the value you just copied from Atlassian in the the Unique ID field, then click Save.
Return to the step-by-step instructions: Testing SAML for Atlassian Cloud (for those users who HAVE migrated)
If you are configuring SAML for an existing integration, you only need to copy your Unique ID from Atlassian to Okta, as follows:
Navigate to admin.atlassian.com.
Note: You need to be a JIRA, Confluence, or Stride site administrator to access this URL.
In Okta, select the Sign On tab for the Atlassian Cloud app, then click Edit. Enter the value you just copied from Atlassian in the the Unique ID field, then click Save.
Return to the step-by-step instructions: Testing SAML for Atlassian Cloud (for those users who HAVE migrated)
Now that testing has passed, you are ready to switch your entire user base to SAML.
The SWA chiclets for Jira and Confluence are no longer functional in Okta. Go to the SWA apps for both, and hide those chiclets from your end-users by checking the Do not display application icon to users under the General tab for those apps.
Now go to your Atlassian Cloud app integration in Okta, and unselect Do not display application icon to users under the General tab, and assign the new application to the groups you identified in the beginning which were assigned to the existing Jira and Confluence app integrations.
There are no additional steps required by your end-users. Once they click on their new Jira and Confluence chiclets associated to the Atlassian Cloud SAML app, they will be logged in via SAML.
Important: Since you are now managing two apps, one for provisioning and the other for SSO, you need to assign both apps to new users. You can do this using Group Rules. See here for more information about using Groups and Group Rules.
Go to your Atlassian account login screen. Can't log in? Follow the prompts to receive an email with a log in link.
Then, go into your site administration to fix or disable SAML for the rest of their users.
The following SAML attributes are supported:
| Name | Value |
|---|---|
| http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname | user.firstName |
| http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname | user.lastName |
| http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name | user.id |