Learn about security solutions and standards
Care about security? We do too. Learn what Atlassian does and what you can do too.
You can now find SAML single sign-on in the same place you manage your identity provider. To find it, go to Security > Identity providers. About identity providers
Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between an identity provider and a service (such as Confluence Cloud).
This page provides the steps to configure SAML single sign-on with Active Directory Federation Services (AD FS).
Who can do this? |
Here's what you need to do before you set up SAML single sign-on with AD FS.
Subscribe to Atlassian Guard Standard from your organization. Understand Atlassian Guard
Make sure you're an admin for an Atlassian organization.
Verify one or more of your domains in your organization. Learn about Domain verification
Add an identity provider directory to your organization. Learn how to Add an identity provider
Link verified domains to your identity provider directory. Learn how to link domains
Let your users know they won't be able to log in to Atlassian products while you're doing the setup
Create an authentication policy to test your SAML configuration . After you set up SAML, you can enable single sign-on for this authentication policy.
We also recommend the following:
Check that your Atlassian products and AD FS use the HTTPS protocol to communicate with each other, and that the configured product base URL is the HTTPS one.
Because SAML authentication requests are only valid for a limited time, make sure the clock on your identity provider server is synchronized using NTP.
Create an Atlassian account that you can use to access your organization if SAML has been misconfigured.
Use an email address from a domain you haven’t verified so that the account won't redirect to SAML single sign-on when you log in.
Give the user organization admin access. You can remove admin access when you are satisfied that SAML single sign-on is working as expected.
Install and run your Active Directory.
Install Microsoft Active Directory Federation Services.
Connect Microsoft Active Directory Federation Services to your Active Directory.
This configuration requires AD FS 2.0+
We most recently tested on Windows Server 2016 Datacenter and AD FS 4.0
Complete these steps to add a SAML configuration from your Atlassian organization for your users.
From your organization at admin.atlassian.com, select Security > Identity providers.
Select your AD FS Directory.
Select Set up SAML single sign-on.
The ability to configure SAML single sign-on for Jira Service Management customers is available for people in an early access program. This feature will be available to everyone soon.
Follow these steps if you want to add a SAML configuration from your Jira Service Management site for your portal-only customer.
From your organization at admin.atlassian.com, select Products.
Under Sites and products, select the site you want to configure the SAML SSO for.
Under Jira Service Management, select Portal-only customers.
Select More > Identity providers.
Select your AD FS Directory.
Select Set up SAML single sign-on.
From the AD FS management tool, right click AD FS from left panel and click Edit Federation Service Properties.
5. From the Federation Service Properties dialog, copy the value under Federation Service identifier.
a. Go back to the Add SAML configuration screen on admin.atlassian.com.
b. Paste the value in the Identity provider Entity ID field.
6. Return to the AD FS management tool, and select AD FS > Service > Endpoints in the left panel.
a. Under Token Issuance, search for and copy the URL path with a Type of SAML 2.0/WS-Federation.
b. Go back to the Add SAML configuration screen on admin.atlassian.com.
c. Paste the path, prefixing it with your server URL (e.g. https://<myadfsserver.com>/adfs/ls/) into the Identity provider SSO URL field.
7. Export your public key.
a. From the AD FS management tool, select AD FS > Service > Certificates from right panel. Right click the certificate under the Token-signing section and click View Certificate.
b. From the Certificate dialog, switch to the Details tab and click Copy to File.
c. From the Certificate Export Wizard that opens, click Next.
d. Select Base-64 encoded X.509 (.CER) for the format and click Next.
e. From File name, specify the path to where the exported certificate should save along with its filename and click Next.
f. Review the settings for the exported certificate and click Finish.
g. Open the exported certificated file and copy the certificate key. Go back to the Add SAML configuration screen on admin.atlassian.com and paste the value in the Public x509 certificate field.
8. Select Save Configuration.
Complete the steps in this section from the AD FS management tool.
From the AD FS management tool, expand AD FS from left panel, select Relying Party Trusts and click Add Relying Party Trust from right panel.
2. From the Add Relying Party Trust Wizard, select Claim Aware and click Start.
3. Select Enter data about relying party manually and click Next.
4. Enter a Display name for your relying party and click Next. This name will appear under your Relying Party Trusts list in the AD FS management tool.
5. From the Configure Certificate step, click Next. You don’t need to encrypt any of the tokens as part of the setup.
6. Select Enable support for the SAML 2.0 WebSSO protocol.
a. From your SAML single sign-on page at admin.atlassian.com, copy the SP Assertion Consumer Service URL and paste the value into the Relying party SAML 2.0 SSO Service URL field in the AD FS wizard.
b. Click Next.
7. From your SAML single sign-on page at admin.atlassian.com, copy the SP entity ID value.
a. Paste the value into Relying party trust identifier field in the AD FS wizard and click Add.
b. Click Next.
8. From the access control policy lists, select Permit everyone and click Next.
9. From the Ready to Add Trust step, review your settings and click Next.
10. Click Close to complete the wizard.
The steps in this section map how AD FS sends claims to your Atlassian organization. This mapping requires two rules that you add to AD FS. The first one maps these AD fields to SAML fields: Email, Given Name and Surname. The second rule maps the Name Identifier.
If you’re using Microsoft Azure, refer to this tutorial, and read point 14 within the ‘Configure Azure AD with Atlassian Cloud SSO’ section. Use the same email address to log in (from the AD) as mentioned in the mapping.
From the AD FS management tool, right click the relying party trust that you recently added and click Edit Claim Issuance Policy.
2. Click Add Rule.
3. From the Claim rule template dropdown, select Sending Claims Using a Custom Rule and click Next.
4. Enter a name for Claim rule name.
a. Copy the following into Custom Rule field.
1
2
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"), query = ";objectSID,mail,givenName,sn;{0}", param = c.Value);
b. Click Finish.
5. Click Add Rule again.
6. From the Claim rule template dropdown, select Sending Claims Using a Custom Rule and click Next.
7. Enter a name for Claim rule name.
a. Copy the following into Custom Rule field.
1
2
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress");
b. Click Finish.
You have two ways to test based on whether you have 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 allowing you to test different single sign-on configurations on subsets of users before rolling them out to your whole company.
You may want to:
Test single sign-on (SSO) or two-step verification on a smaller, select group of users to ensure it is setup 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 test the settings for authentication, you'll need to configure and enforce SAML single sign-on. The following section provides instructions on how to do it.
Your SAML configuration applies as soon as you select 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're signed in. If you experience a login error, go to the Troubleshooting SAML single sign-on to adjust your configuration and test again in your incognito window.
If you can't log in successfully, delete the configuration so users can access Atlassian products.
Was this helpful?