Hi all,

Atlassian added the documentation Configure SAML single sign-on with Active Directory Federation Services (AD FS) with instructions to integrate with ADFS and the page SAML single sign-on has been updated.

Gabriel
Atlassian Support

I have SSO working with AD FS 2.0

Hopefully these update screenshots will help - it looks like things have changed since the post in Dec 2016.

Enter on Atlassian side

Identity provider Entity ID:

http://adfs-server.domain.com/adfs/services/trust

Identity provider SSO URL:

https://adfs-server.domain.com/adfs/ls/

Public x509 certificate:

Export your Token-signing certificate as base 64 (how to get from AD FS 2.0 console: AD FS 2.0 -> Service -> Certificates)

Enter on AD FS 2.0 side

There are only 2 tabs that you need to populate with information - Identifiers and Endpoints but I've included screenshots for everything.

Edit: looks like I can't upload new screenshots.

In short, I used these values:

Identifiers tab:

Relying party identifier: SP Entity ID from sso config page on admin.atlassian.com

(eg: https://auth.atlassian.com/saml/hex-string)

Endpoints Tab: SAML Assertion Consumer Endpoint: SP Assertion Consumer Service URL from sso config page on admin.atlassian.com (eg: https://auth.atlassian.com/login/callback?connection=saml-hex-string)

Advanced Tab: [default - SHA-265]

Don't forget about the claims rules (see screenshot from Dec 2016 post)

Claim rules are the same as the earlier post:

Ra maader cood kankemaager pola R a

Once you register a domain for SSO, any user who self identifies (or has self identified) their email address as having that domain (exact domain, not subdomain), is now in your access management / SSO cohort...

We are also a higher ed org and have the same problem with Atlassian Access. We are hopeful that in the future there will be a way to identify just those sites that we'd like included in our Atlassian Access subscription. It seems like a number of students in our computer science courses use Atlassian cloud products, which is great! I'm all for sending students off into the work place knowing how to navigate a Jira project. But the University IT department doesn't want to pay for SSO for them, only for our centrally supported site and our dev site. 

Someone from Atlassian called us to discuss this issue, which helped us understand it, but she hasn't responded to my emails since. I would be more than happy to discuss this higher ed use case further as it is a major blocker for our implementation of Jira Service Desk. 

Is there option to only bring in certain domain users, like from a certain OU or any way to filter for only a certain set of domain users?

Like you we have over 600 staff but only a small set use Jira.

this issue is closed as "wont fix", so you cant vote for it

https://jira.atlassian.com/browse/ACCESS-37

Yes!  Ridiculous right??    I registered @upenn.edu.  Single sign on worked.  I dont like that I have to pay for 600 users to SSO, but whatever.  Then I got a notification from our business school.   "Why are half of our users now mysteriously using SSO??"   Uh... anyone with @upenn.edu is now SSO.  Thats ok too, perhaps a feature, except that now we own those accounts and have some control over them.  But then they are on our IAM bill paying per month per user even though they arent in our Jira/Confluence cloud site.  And other alumni who are in random sites are now SSO and we pay for it.  Thats another 600 users right now, and will grow (uncontrolled by us)  Can we charge the other departments back?  No, they didnt ask for it.  Should we have to pay?  No.  So now we can either turn off SSO which we dont want to do.  Or go back to on prem and save 30k per year and have more user licenses (cloud doesnt have edu discount).  Twist my arm...

Hi Chris\Elanor,

Can you just explain what you mean by "Now users who use our domain in their email are on our bill" ?

So if you set up SSO and add your domain it charges you for all your domain users and not just the ones that actually have a login for JIRA\Jira Service Desk etc?

Thanks

Niall

We integrated our domain with SAML.  Now users who use our domain in their email (who arent in our cloud Jira site!!!  but who are alumni...) are on our bill.  We will be pulling back from cloud and going back to on prem sadly...  big step backwards only due to over-billing...  if Atlassian will do what other vendors do and give SAML for free they should let us know the plan asap before we invest back in on prem. 

With the lack of built-in SAML support in Bitbucket Cloud and a hard-to-believe pricing of the separate Atlassian Access product, we have looked at automating user access using Bitbucket Cloud API and https://github.com/terraform-providers/terraform-provider-bitbucket. Unfortunately only V1 of the Bitbucket Cloud API can manage groups, users and invitations and the V2 of the API can't (see https://developer.atlassian.com/cloud/bitbucket/deprecation-notice-v1-apis/). Is it on purpose?

I have asked Atlassian but there is no plan to migrate all V1 functionality to V2 and since V1 is deprecated and related API endpoints will be removed in Dec 2018 (see https://confluence.atlassian.com/bitbucket/version-1-423626337.html) we will have no way of automating user access. We wanted to contribute to the Open Source Terraform Bitbucket provider but it strictly allows only functionality which exists both in V1 and V2. Currently we can only effectively use it to automate management of repositories.

Agree with above comments! Adding this one in the event that Atlassian considers these valid concerns from their use base

 Adding a +1 in the unlikely event that it actually matters.

User Authentication and Identity is a basic feature that should be offered for free as part of the value proposition of using the Atlassian Cloud suite. 

To charge $2/user/month up to a thousand users for something so trivial as SAML authentication is an absolute rort especially when you consider that Bitbucket is $2/user/month, Jira is $1/user/month, Confluence is $1/user/month at these higher volumes.

If you were going to charge such an outrageous amount then at the very least there should be APIs provided so that you can automate the process of deactivating accounts. I have over 200 active accounts from staff who have left my company. I've removed them from Jira and Confluence with a one click operation but with Atlassian Access its a 4 click operation to deactivate that I don't have hours in my day to repeat 200 times.

I dislike that although I use my company's Jira and Confluence Server instances, just because I have an Atlassian account my company will be charged.  I'm not using cloud!  I made the account 3 years ago so that I could access and contribute to the forums.  Everyone contributed to the forums, providing free help to users where Atlassian possibly could not.  Now Atlassian is effectively charging for access to what was a free resource, provided free to them.  This stinks.

I am really disappointed, as my company were finally going to adopt Atlassian cloud, with very much greater usage.  We have hitherto just used Jira server, and only Confluence server (in a small group) recently.  This money gouging is really putting the management off, so we may be stuck with our limited server usage.  I was hoping the whole company (2000 + users possibly) were going to adopt Confluence, which was going to increase its usefulness greatly.  It's looking increasingly unlikely now.  

I don't have much to add except to also express my frustration with the pricing model.  It's increased our spend on Atlassian products by 30% for what we get for free from our other cloud providers.  Given that SSO is a feature we expect (and assume) the mental math will just have to be adjusted to raise the price we're paying for JIRA, etc.

I am very disappointed in Atlassian's decision to charge for SAML/SSO to an external IdP. It should be a basic, free feature just like it is for numerous other cloud service providers such as Salesforce, Xero, Freshdesk, Manuscript and Gitlab. It took long enough for them to provide this in the Identity Manager beta! This is a dealbreaker for us, Atlassian are asking us to pay to be more secure - it says to me that Atlassian don't understand their customers, the cloud, or security.

I think the part that atlassian have chosen to avoid, is that by enabling SAML, it means that there is more appetite to consume their products at an enterprise level as SAML is a basic security requirement as part of most SAAS implementations these days. IMHO Atlassian should be providing the identity layer for free as this simple gesture would help to increase security overall and help them to grow cloud adoption.
The other issue is that from an office 365 layer, there is a single atlassian entity so there is no way to control Trello/bitbucket/jira/confluence usage.
Atlassian really need to provide their SAML access manager product for free to avoid upsetting their large enterprise clients.

Yes this is stupid.
Most enterprise already have an existing Identity Provider (Azure AD, G Suite / Google Cloud Identity, Okta, OneLogin, ..) that contains all their users and implements password policies.

All we want here is the SAML link to authenticate using that IDP.
This should be standard feature and included in the already expensive Atlassian product's licenses.

For our users the bill is around an extra us$3000 per month at this stage as many of our users are already users of other atlassian products and other instances. It doesnt feel right but it appears to be what atlassian feel is the "going rate" for this very basic feature. Out identity bill is way in excess of our cloud spend bill on the other atlassian products.
Even if our users have at some stage used our organisations email to interact with atlassian support services, we are now apparently expected to fit the bill.

So as many of you have probably heard, Atlassian are now going to be charging for this, despite how broken it is in various scenarios.  I cannot understand why my business has to pay $33USD PER MONTH for this for my 11 users, when all I want is 2fa for my users, which is following good security practice, but I have no access to this without spending the money....Very disappointing.

We finally switched to on-premise versions of Atlassian software. The cloud versions are simply too "crippled". Not only when it comes to SAML/Active Directory integration.

We have just started to trial Jira and confluence Cloud to add to our existing LDAPS backed Jira and Confluence on-prem server offerings, and like others, I find it staggering that SSO requires a separate product and separate product licensing which is greater than the cost of consuming the products themselves.
It also presents an added cost each month with any email account within our organisation that has been used to register for any Atlassian service - these must now be identify users with a per cost per month - its simply price gouging especially when we have access to a rich bouquet of products under our existing office 365 subscription.
Atlassian products are just one of many we use in our organisation - the Atlassian IM will never be centre of our universe - it's just an annoying layer that is needed for the SSO integration for the cloud products.

I must agree that SSO in 2018 cannot be separately priced feature - you guys might loose your competitive edge with this.

@ipotrusaev

It was a combination of multiple tutorials:

https://aws.amazon.com/blogs/security/how-to-enable-your-users-to-access-office-365-with-aws-microsoft-active-directory-credentials/ (to set up ADFS)

https://confluence.atlassian.com/doc/saml-sso-for-confluence-data-center-879955981.html (to properly set up Atlassian specific attributes in the SAML assertion)

And then a trial-and-error approach with assistance of Event logs on the ADFS server (they contained a plenty of useful info about what is wrong with the token until i managed to configure it right)

@new.mimacom.infra.management 

Do you have working Atlassian Cloud and ADFS integration? Could you describe how did you configure it?

Just found next feature that would be really nice to have - IdP initiated sign-on. SP-initiated works for me, but when I try to sign on from our ADFS page right away, Atlassian page shows an error.

Identity Manager is too expensive. Other SaaS vendors provide SAML function for free.

Separate price for SAML (Identity Manager) does not make sense to me either, as this "product" cannot be used separately anyway. So the customer must have already paid for one of the "regular" Atlassian products.

By the way, it would be really nice if also group membership could optionally be synchronized via SAML token, i.e. i make someone a member of jira-administrators in an AD and this role is automatically added to that user the next time they log in.

In my opinion it gets even worse if you want to provide SSO to your Service Desk customers! You have to pay for every managed user, even if they don't have a Jira or Confluence license!

I don't want 2 factor or password policies for my Service Desk customers! I just want to make it easy for them to log in to the Service Desk Portal with their Azure AD credentials! And this should be cheap - or maybe even for free...

Considering the Jira overall pricing policy it makes sense to make this a payable add-on. That beeing said the costs are extraordinary compared to other services. I guess most Jira customers would like to have SAML to make their users create requests through the portal instead of by e-mail so it shouldn't be much more than a sync to between ADFS and Jira.

Please consider a different pricing policy, split up the different modules (two way auth, password management, etc)

As said above, most other parties offer SAML for free! 

I second the two comments above. The solution is too expensive when the same functionality is provided by everyone of my other SaaS vendors for free. For this reason we are not putting any further groups on Jira/Confluence/HipChat and instead considering putting them on MS Teams because I already own that. Won't cost me anything.

Exactly. They are charging like they are going to be the IdP. They are not. They are just going to be a slave to a real IdP like Okta, or AD. Cash grab.

My understanding is that to use SAML for Jira, I have to enroll in Atlassian Identity Manager (right?).  If I have 1000 users in Jira, that is $17k/year.  And to use SAML SSO for 1k users, I have to pay $30k/year for Identity Manager??????   If Im using SSO I dont need password policies or two factor (or any other features of Identity Manager), so it buys me nothing other than reading the SAML assertion and populating the username.  I think that should be free, it should save money for Atlassian not having to worry about users complaining about signing in, and not having to worry about passwords being compromised.  It should reduce the price of Jira...  Ugh, might be too expensive to use...  please make SAML free or a fraction of the cost of Jira...

So we got notice we need to adjust our saml config...got it all lined up and working, then says we are unverified (yet we are verified)...we received a page that states support will contact you in 24 hrs...yeah that wont work for folks, especially since support never contacted us...

thoughts???

Atlassian, could you provide an official update to this ticket with status/timelines?

Regards.

I wanted to reiterate what Alex Osipov has mentioned, functionality on IOS is critical to the success of SAML implementation

First, it is great to see Atlassian officially supporting SAML integration in Atlassian Cloud. I am a member of the InCommon (US Higher Education federated identity federation) Technical Advisory Committee. SAML is the standard SSO protocol for higher education research and education collaboration across thousands of institutions throughout the world. Many of them use Atlassian products for development and collaboration. This work could significantly ease integration / collaboration across higher ed.

Reading through the integration instruction, I am finding that there are shortcomings. I do have a number of concerns regarding a few design choices that may seriously hamper collaboration scenarios where users come from more than one IDP. In particular, the choice to use email address as a unique identifier and the lack of support for users from multiple IDP accessing the same (Confluence/Jira) instance. I'd like to follow up with the right party. What would be a good way to get in touch?

We would like to use Atlassian Id authentication to Bitbucket. When will this be possible?

Would love to see SAML working with iOS app, its the only place where our SAML implementation is not working (Android and web is fine)

I'd love to see Duo Access Gateway added as a supported IdP.

Due Security are one of the MFA market leaders, and I'm sure many customers would welcome the addition of Duo Access Gateway as a supported IdP.

Has anyone been successful getting this to work with PingFederate?

Hi Everyone,

With regards to the SAML 'single sign out' issues from the Identity Provider (in my case Azure AD) I have gotten the devs to open an official issue with regards to it - they are now very aware that it is a problem and at least have an issue to resolve it.  If this is also affecting you, please give it an upvote! Issue link is https://jira.atlassian.com/browse/ID-6396. Thanks in advance.

Is it not possible to update firstname and lastname when saml login occurs? Pretty normal feature every implementation I have seen does.

A few feature suggestions that would make this viable for the Enterprise, considering SAML is the only way to implement MFA on JIRA cloud:

• Enforced login of a site using SAML or not allowing Atlassian username/password access.
• A way to control the authentication method for all users of a site, including 3rd parties where it is impossible to claim the domain.
• A separation of the identity username and email address - not all identities in Azure AD, for example, have a mailbox.  Whilst it is possible to claim the domain and have the users authenticate via SAML for these domains, email will be undelivered unless there is a mailbox with the same address.  Allowing an alternative email address or multiple email addresses would work too.

Please open a support request in support.atlassian.com to have this issue further investigated and, if needed, a bug ticket open to have it addressed.

Cheers,
Dario

@Tim Freeman - Yeah I checked both sides, Atlassian and Azure AD. Same results as you.

@Jim Pickering - Thanks for testing it, at least it means I'm not going mad! Were you talking about the setup on the Atlassian end or the Azure end? I looked at both and didn't see anything either - From the link above that I posted I am still quite sure that Atlassian needs to be managing it themselves.   I also found this link - https://azure.microsoft.com/en-au/resources/samples/active-directory-dotnet-web-single-sign-out/ -  which is a sample app that performs the sign out using a cookie-based method, which again would need to be something Atlassian implements.  Hopefully they will look further into this!

–

@Kris Hen - That is an interesting thing you've discovered. We are using SAML with Azure AD and we get the login error just as your described. I reviewed the SSO Setup and there is no place to even indicate a Sign-Out URL.

I haven't found anyone already commenting about this, but is anyone currently using SAML with Azure AD and finding that if a user logs out of (in our case) confluence, it doesn't log them out at the Azure AD end? This means that if a different user on the same machine tries to sign into confluence, it tries to pass the azure AD login information of the previously logged in user, resulting in a mismatch and a login error - this is quite frustrating as there is no simple way to log out the previously logged in user's Azure AD account! It looks like Atlassian should be doing something like the following: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-single-sign-out-protocol-reference but I cannot say if they are doing something like this and it isn't working, or they haven't got around to supporting this properly as yet...

JIRA Capture needs to support SAML logins via Azure AD as well. We have this functionality working with our verified domain for JIRA Software, JIRA Service Desk, and Confluence in Atlassian Cloud. JIRA Capture requires non-SAML Atlassian login though, which we wanted to avoid having our Testers having to fuss with.

We are in process of evaluating JIRA Cloud. Currently we have JIRA Server for 2000 users. I was looking at this feature request and the instruction to setup SAML for cloud. We use PingFederate as our SSO solution and it seems you mention it on the article with comment that its coming soon. Do you have ETA on when will it be available? is there anyone who have successfully configured SSO with PingFederate for JIRA Cloud and Confluence Cloud?

My company has two JIRA Cloud accounts. One is a pilot account (siteA.atlassian.net) that needs to continue until it can be moved into the new full company account (siteB.atlassian.net). The full company account (siteB.atlassian.net) needs to have SAML enabled, which will work fine, but it makes it so the users of the pilot account (siteA.atlassian.net) are unable to login. Can SAML be enabled for both sites?

I'm looking at authenticating our Service Desk customers via SAML SSO against our IdP.

I was looking at the documentation on this page:

https://confluence.atlassian.com/cloud/saml-single-sign-on-873871238.html

Seems like in order to enable SAML, I need to claim my domain(s). As far as I can tell, only logins belonging to the claimed domains will trigger SAML SSO (conversely, any login that does not belong to a claimed domain will not be able to log in via SAML). Is this assumption correct?

Say my company's domain is thiscompany.com, I claim that domain and enable SAML SSO on my cloud Service Desk. My customer's email is jack@anotherdomain.com. Will he be able to log in via SAML?

If not, how do I enable SAML SSO such that my customers can use their own email address to sign in to Service Desk?

Thanks in advance!

Are there plans to adjust current functionality to better support multiple tenants sharing accounts? The way domain verification/ownership takeover works is flawed if your company uses vendors who may also have their own Atlassian Cloud environment.

We have vendors who access our environment with their company email credentials on domains we don't own. We should able to funnel these through our SAML provider, our source of authorized vendor account information, for authentication without impacting their own companies Atlassian Cloud account.

An example of how this should be handled is how New Relic handles SAML, its on a per-account bases not per-email domain basis. When you toggle between different accounts within New Relic, if necessary, you will be re-prompted for authentication through the appropriate provider (depending on if the account is authenticated by New Relic itself or by a SAML provider).

Okta support is coming in Preview Release 2017.10, which probably means we're a few weeks away from Okta production release.  https://support.okta.com/help/Documentation/Knowledge_Article/Okta-Preview-Sandbox-Release-2017-10

@Thomas

The catch 22 you described is actually how the SAML spec works, Okta just hides that with OAN (Okta Application Network) applications.

mrussell@atlassian.com any updates?

Hey Everyone,

We've been using JIRA with Okta using the Generic SAML2 application in parallel with the JIRA Cloud application for provisioning (see #3 for details).

Steps should be standard for creating a generic SAML2 app, except for the following:

1. From what I remember, Atlassian has the SAML2 process backwards causing a catch 22. You'll need to create a Generic SAML2 app, but you will need to leave this half empty so you can generate the details to hand over to JIRA. From there, you'll be able to generate the rest of the details for Okta.
2. Default relay state should be set to your JIRA cloud instance with the trailing / included (i.e.: https://tickets-r-us.atlassian.net/).
3. Make the Okta-verified JIRA Cloud SAML2 app hidden to your users since you'll need to maintain two apps in Okta.

Our global team have been using this in production for about a month without an issue, with the exception for an unscheduled JIRA Cloud outage that coincided on our SSO cutover date/time.

For testing, keep in mind that when you do switch it on and intend on shutting it off again, anyone that has completed the JIRA SSO onboarding step will need a password reset once it's turned off.

Also, the catch 22 in the above point #1 is likely the dependency that's holding up Okta from adopting it. I'm guessing Okta & Atlassian are going back and forth on changing the process in JIRA to eliminate this catch 22. If you have an paid Okta account, you can contact the Okta support team with the Okta-internal ticket REQ-7770 to add more weigh to the importance of the issue on their end.

Hopefully this helps move this along. Happy to send over screenshots over LinkedIn if anyone has questions.

Thomas Madej
Console Connect
https://consoleconnect.com/