With the release of external user security and the closing of ACCESS-102, we are re-opening this ticket to continue to track customer interest in cloud site level SAML SSO. 

Thanks everyone for watching and commenting on this ticket. As part of an initiative to better consolidate customer feedback, we are closing this ticket as a duplicate. Please vote, watch and comment on ACCESS-102 going forward

Need to comment on this as well. We are heavy SSO-Users for both internal (own domain, own IDP) and externals (either guest in our IDP form their own domains (like Armin@customer1.com) or even collaborated external IDP's that have a trust with our IDP (Carol@customer2.com or sandra@partner1.com) for our cloud-hosted applications and services (in the latter case, the external IDP admins can even assign groups/roles to their users by themselves and give their users access to our applications this way. 

With all of our SAML-applications* we can both use it for our staff as well as our collaborators. This gives us the security level we need (e.g., enforce MFA via the IDP, have no auth-data stored within the same service where data resides) and gives consumers of our services the convencience to work in an integrative environment where they auth with their reals business entity (also a question of better trustability and easier self-services) and the lack to maintain passwords (They were outdated when they were invented! or do you still think a "complicated" 20digit Alphanum is a real issue?)

*There is one exception to it - unfortunately - and I cannot find a workaround: ATLASSIAN-ACCESS (purchased to enable SSO for Atlassian products, while others have that by default. Granted! But even payed it does only work for your own domain users? Who the heck had this genious marketing idea? Did Atlassian not advertise with COLLABORATION? Collaboration with whom? The idea could have sprung out of a government brain. But 2021-businesess collaborate without formal borders and need even more secure cloud applications to do this and still comply with legal regulations regarding privacy and data-protection. Currently almost impossible with Atlassian Access if you want to collaborate with externs (btw, payed licenses! I dont even discuss the "guest" desaster, where you would want to give a bigger customer audience access to their specific customer-documentation). As a result a much smaller solution is currently developed for us lacking some of the "bling" but providing efficient security and collaboration.

One possitive comment though: detecting, that a user is SAML-enforced (when he formerly signed up as a user-pass dinosaur) in ACCESS works like excepted though and this is something where we often struggle with other implementations if not "tuned".

Please understand, while many bigger corps do have Atlassian-licenses, they mostly have them on department levels (and therefore compliance is on submarine level) or use on-premise servers with stone aged security concepts. That the bigger corps do have the licenses does is not too rarely caused by external staff (freelancers or consultants who actually want to collaborate via Atlassian products). Regarding this, see my comment avbove...

The majority of customers have at least one major IDP running nowadays to manage identity, trust, authentication and authorization, while keeping it de-centralized on org-levels). Instead of keeping head-of busy with writing permit-requests for their teams, they are assigned roles to give access to defined resources by themselves (This once was the idea behind the Atlassian authorization concept as well...). To implement zero-trust concepts  a fully functional IDP is also critical for any application in my tool-chain.

So please do not underestimate the weight of the issue. SAML/OPENID/SSO is only effective if I am able to minimize the amount of entry-risks by local users and making every user a first-class citizen in auth with IDP control. Without it, anyone storing business data (so basicly anything beyond vacation blogs) basicly puts himself at risk compromising that data. And unfortunately the situation becomes even worse if that data is not yours.

I must say I find it extremely strange that there is no technical way to manage both types of accounts in a secure way - meaning that we should be able to enforce security login options also for users not in claimed accounts.

The result will be that we will have to create internal users for all our external users in Azure, meaning that in addition to paying for Access we would also have to use licenses for external users in our Azure AD to ensure proper security in our Atlassian tools. Not good.

With a really high focus on security with many of our customers, establishing a technical solution to be able to enforce desired level of security when using your systems, for all differently managed accounts, is an absolute prerequisite to be able to promote cloud as a viable solution to our customers.

Please ensure a proper focus on this issue internally in Atlassian.

without it, apart from ease of access (limited as we are using password managers), there's not much security benefit to SSO as we would have lot's of third party collaborators on our site...

Github has a nice interface for doing this and enforcing it as well as a nice UX for signing on.

The ability to enforce SAML SSO for unmanaged accounts is something we would like also.