Configuring Atlassian Cloud Single Sign On for ADFS 3.0

Atlassian don’t officially support AD FS with Confluence Cloud – but it is working well now I’ve sorted out the issues I was having passing user’s email address through as the nameId claim. Hopefully these instructions can save you some trial and error.

Enable SAML on Atlassian Cloud

  1. First off – enable SAML on your Atlassian Cloud instance at https://<subdomain>.atlassian.net/admin/saml/edit
  2. The Identity Provider Entity ID can be found in the Federation Service Properties in ADFS – but typically will look like mine –
     https://adfs.jamesnimmo.co.nz/adfs/services/trust
  3. Identity Provider SSO URL can be found in  AD FS Service > Endpoints – look for the SAML 2.0 type, but it should just be
     https://adfs.jamesnimmo.co.nz/adfs/ls
  4. Open up your token signing certificate in AD FS, then select ‘Copy to file’ from the Details tab. Save with Base64 encoded as a txt file – then copy the contents into the Public x509 certificate field.
  5. Save configuration

Add Relying Party Trust wizard

  1. Add a Relying Party Trust to AD FS. On the welcome page select ‘Enter data about the relying party manually’
  2. Select a display name – i.e. Atlassian Confluence
  3. Use the AD FS profile (supports SAML 2.0)
  4. Leave the token encryption certificate blank
  5. Enable support for the SAML 2.0 WebSSO protocol – and enter the SP Assertion Consumer Service URL from the Atlassian Site Administration > SAML section. Currently this is:
    https://id.atlassian.com/login/saml/acs
  6. For the relying party trust identifier, enter the SP Entity ID – currently this is
     https://id.atlassian.com/login

    Please note, do not be tempted to add additional relying party trust identifiers (I had added some others in here which caused it not to work)

  7. Optionally configure multi factor authentication settings

Configure the claim rules

  1. First create a rule to send attributes from Active Directory to Atlassian Cloud. I think the only mandatory claim is the email address.
  2. Next, add a second rule to Transform an incoming claim
    (this is another step I hadn’t figured out the first time I tried to configure SAML – without this step it seems like ADFS doesn’t use the right format for the outgoing name ID).

Test it out

I haven’t got Identity Provider initiated sign on working yet (via the /adfs/ls/idpinitiatedsignon.aspx) – but if you use a RelayState URL – and then put this in your corporate bookmarks etc it should work nicely (replace the <yoursubdomain> part

https://adfs.jamesnimmo.co.nz/adfs/ls/idpinitiatedsignon.aspx?RelayState=RPID%3Dhttps%3A%2F%2Fid.atlassian.com%2Flogin%26RelayState%3Dhttps%3A%2F%2F<yoursubdomain>.atlassian.net
This entry was posted in Admin Tips. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

One Comment

  1. Devon
    Posted August 1, 2017 at 7:02 am | Permalink

    Hi James,
    Great article and just what I was looking for but I’m falling short in the configuration somewhere…

    When I use atlassian’s login page it gives me a timing issue (I imagine that is what you are running in to also) but when I use the relayState URL it is trying to take me to https://id.atlassian.com/login/saml/acs and says “Oops you’ve made a malformed request”

    Do you think it’s an actual clock issue (we are synced to government ntp pool) or something to do with one of the claim attributes?

Leave a Reply