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

The issue that Chris identified is one of our primary concerns with Atlassian Access. Until this issue is resolved we won't be able to use it because we won't be able to control our bill at all. Pretty please resolve this billing issue! It's embarrassing to have a Help Center that's not behind SSO for the department that brings our larger organization SSO.

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?

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/

Any update ?

Hello, A few questions about this release:

1. When will you have setup instructions for Okta? An ETA would be good to so that my company can plan internally (we're on Okta and many of your Cloud products and would LOVE to use this).
2. Will this SAML integration cover all the products you offer, specifically Jira Software, Jira Service Desk, Confluence, and Hipchat? These are the products we've invested in (+ Portfolio but we don't see a need for SAML for that) and want to leverage this for all of them.
3. Do you need any test customers? We'd be happy to volunteer!

Thank you!
Tonya Mompoint
CareerBuilder

@mrussell@atlassian.com 
The users have verified email on the domain. We still have the same issue with those users.

Also we noticed that, the users who were able to login via SAML no longer can login, however, if they use their previously cached/old credential they can login successfully.

As of now, all the SAML users get the following error when try to login:

While we did not make any changes to the setting, this happened. The troubleshooting shows that we get a valid token but when redirected to Atlassian the request is malformed. We use Centrify with custom SAML application.

I had made sure that all the attributes are mapped, including the nameid to be present as email. The refer url goes to https://id.atlassian.com/login/saml/acs .

@mrussell@atlassian.com  If there are no plans on removing the Login with Google button from the login screen is there a way we can disable users from logging in using Google authentication. Currently users can either use SAML or the Google button to log in even after disabling the connection to Google Apps.

I got the same error as @joe.dropkin1931291160, there's no signle sign on option as we're already using Atlassian account.

@Joe, I had that error when testing in Okta as a generic SAML2 app. You missed a step and need to enable Single Sign-on in JIRA.

I set up a generic SAML2 app in Okta and could not get this to work.

@Matthew Russell I've communicated to Okta support and the feature request is internally tracked at Okta with ticket REQ-7770. I would recommend that Atlassian and all it's customers communicate to Okta to expedite the connector by referencing this ticket number.

They've communicated that the work-around currently is to provision a generic Okta SAML2 app and configure JIRA to use those details. However, if you use lifecycle management, this workaround requires you to maintain two apps within Okta, one for provisioning and one for SAML2 auth.

Sorry parker.despain699968528, I've been in touch with Okta multiple times since your original question, and status hasn't changed. They're still in progress with their connector. They suggested for those interested to send an email to support@okta.com or open a case directly at https://support.okta.com/help/open_case. This is not really in our control at this point - we're as keen as you are to see it available. 

sracherla969129257 - I'll assuming you're looking at testing while Atlassian account is enabled (Single sign on is turned on). Deleting a SAML configuration does not send password reset emails. If, however, someone goes through login while there is no SAML configuration, they will be able to login with their password (or able to set a password with password reset). Please be aware that while you're testing with your Test IdP, all logins for your users will be going through that IdP - so you will likely lock out some users. We have better testing capabilities in mind for a future enhancement. 

hairom1715481686 - If the existing Atlassian account has an email on the domain you have verified, this should enforce SAML for them. Are you still experiencing this issue. There are a few valid edge cases that explain a failed SAML authentication. If you're still experiencing it, I'd recommend raising a support issue so we can investigate. 

So is that a No!!! on the Okta thing, or are you just ignoring us to be hilarious?

^^ I'm waiting for the exact same thing, fingers crossed...

Please provide on update on SAML for okta.

Can an update be provided for when this will be available for Okta? 

@mrussell@atlassian.com
We have 2 idp instances- idp Test and idp Prod
SAML implemention workflow:

1. Implement idp test
2. Test the implementation
3. Delete the idp test
4. Implement idp Prod

How will the end users/admins be affected by this? Will the users get a password reset email or go back to Atlassian account password when we delete the SAML configuration?

Thanks.

Yeah.  Mine is working today as well.

I used Chrome. After contacting Atlassian Support, this was resolved.

I used Chrome, Firefox, and IE

stephen_brile1875246223 & dfriedman722787694 - what browsers are you using? 

miller.jira699748083 - Deleting the SAML config won't send a password reset. It will be possible for people who've successfully logged in with your SAML to have no password set on their Atlassian account, but they will need to perform their own password reset. If you turn of Single Sign on, you are pointing your site back to our legacy login system, and anyone who has successfully authenticated with an Atlassian account will receive a password reset in that case. For your mismatched email question, existing domain users will not be able to authenticate, though they will not be deactivated. I hope that answers the question?

mreilly326238220 - The main component of support for ADFS comes in the form of documentation from Microsoft. Since Microsoft are not planning on providing documentation / configuration guides, we don't want to set an expectation that our support engineers will all know the in's and out's of ADFS to help you get set up. Microsoft have recommended Azure AD as the solution with ADFS. 

For troubleshooting if I delete the SAML configuration, will the users get a password reset email or can we still implement SAML again without effecting the users? 

^^ I just submitted a support ticket about this issue.

When I click the verify button from my domain, I do not get a window that lets me download the .html verification file.

I see that email id's are case sensitive, what if the email id's do not match?
Will the existing domain users be deactivated?

I wonder: Why no official support for ADFS as an IdP?

Per: https://confluence.atlassian.com/x/bJlCMw 

"We don't officially support ADFS, so we recommend using Azure Active Directory instead."

sracherla969129257 - you are correct. The implementation on your DEV instances will impact login at your PROD instance. 

nmoore@co.pierce.wa.us - To add to Russell's point, my language may have been ambiguous - the users are provisioned automatically upon arrival at your site. So of the 2500+ users who can authenticate with SAML, only those 150 that arrive at you Atlassian site will have accounts created for them, when using domain restricted sign up in combination with SAML.

DevReports195286775 - it should be your IdP password. Your Atlassian account password is now only used for API authentication. 

******************
Testing Instructions:

1. Open a new incognito window.
2. From your site's login screen, sign in with an email address on one of your verified domains.
3. Confirm you are signed in correctly and have all the expected access.

******************
After implementing SAML, do you have to use your Idp password or Atlassian Account password to login

Thanks.

@ Nate Moore

I dont know what SAML provider you are using however with Azure you can assign apps per user or group (if you have Azure AD Prem) and that can be a control mechanism...also with ADFS you can restrict to domain group who is authorized to leverage the appropriate claim

Matthew - regarding your comment on Jan 2 about automatic provisioning:

If you have Domain Restricted Sign up configured on your site, with SAML enabled on that domain, you will get automatic provisioning. If an user with an authenticated IdP account arrives for the first time, they will go through the SAML dance, and arrive back at your site as a new user, with "default access" groups that you have configured.

What is the solution for when you're not providing accounts for your entire enterprise?  For example, we have 2500+ users who can authenticate via SAML, but only 150+ who need JIRA access.  Is there no mechanism for only using SAML for authentication?

@mrussell@atlassian.com 

Thanks for the info.
"If your PROD instance does have Atlassian account, then testing on a DEV instance will not provide you a sand-pit. All configurations on your DEV instance will apply to all Atlassian account enabled sites" 
Does this mean even if I implement SAML on a DEV intsance, the users will have to use their Idp password to login to their PROD instance?

Thanks!

@Matthew Russell: Fantastic. Enabled domain restricted signup and provisioning works fine. It would be even better if it skipped that middle step of hitting the login screen, but it will work for now.

Another feature I might suggest for the future is reading the group memberships the SAML provider can push across and automatically place the user in those groups if they exist on the Confluence side.

Thanks!

brett.wiard980557619 - we are close to having IdP initiated SAML complete - we hope to have that incorporated before we go to public beta. Timescale here is days/weeks. 

aaron.pollock1141433412 - Thanks for your feedback! We're looking at improving the configuration page to include a feedback button. For your questions: 

• We have an ability to suppress the invite to a user coming soon also. 
• There are no plans to remove the Login with Google button from the login screen, as this login screen is used across all of Atlassian account - it is not customisable per customer.
• If you have Domain Restricted Sign up configured on your site, with SAML enabled on that domain, you will get automatic provisioning. If an user with an authenticated IdP account arrives for the first time, they will go through the SAML dance, and arrive back at your site as a new user, with "default access" groups that you have configured.

sracherla969129257 - If your PROD instance does not yet have Atlassian account enabled, you can safely test there (SAML configurations only apply to login with Atlassian account). If your PROD instance does have Atlassian account, then testing on a DEV instance will not provide you a sand-pit. All configurations on your DEV instance will apply to all Atlassian account enabled sites. This is a quirk of the single-account nature of Atlassian account that we are looking at solving with better test capabilities within the configuration. 

@Brett Wiard

I had it running for a bit and when it was enabled, if I went to domain.atlassian.net it piped me over to the SAML page...but post login it had me do a quick validation...

I would love to be able to an IDP into it so I can 302 page and make it friendly, ie atlassian.internaldomain.net and that lands on a page to log into pass credentials into the system, no email, etc...did it with new relic and ADFS (ADFS is still unsupported for this beta)

Are there plans to have SAML send the user to <domain.atlassian.net> instead of id.atlassian.com? This causes the user to have to enter their email address, then click the <domain.atlassian.net> URL inside their Atlassian profile page.

Is there a place for customer feedback surrounding the SAML features? Specifically, I'd like to see the following implemented:

• No invitation sent when adding a user that will be logging in with SAML. There's no need for them to have that, as they'll just be clicking the Atlassian and/or Confluence button in our SSO provider.
• Removal of the "Log in with Google" button on SAML enabled sites.
• Auto-creation of accounts for people that log in with SAML which get placed into the default "confluence-users" group.

I love a hands-off deployment where I wouldn't have to send invites to every employee (That when clicked, sends them to a page that tells them they have no access to view it).

Cheers!