We are happy to announce that we are rolling out the ability to enforce single sign-on for external users to all Atlassian customers over the next couple weeks!

You can read more about how single sign-on for external users will work in this community article! 

You can also preview a demo video of the feature here.

Expect to see this available in your Atlassian org sometime in the next couple weeks. We will update this ticket again when we are 100% rolled out.

Thank you again for all your feedback, we hope this feature helps you all collaborate more securely. 

I also just tested this, and where you might be using the Atlassian mulitple portals, the customer is sent back a url for the wrong portal.  

We use AzureAD (entraID) as IDP. After an external guest account has been created and the user has accepted the invitation, he can select the "Atlassian Cloud" icon on https://myapplications.microsoft.com/
SSO does not currently work for AzureAD guest accounts with "something went wrong"

Does not provide this feature a solution for our usecase?

@22b0dec13df2 - I have reported similar issue as well. It appears that IDP initiated sign in flow is not supported yet. If users use the Atlassian site's URL, they are able to sign in (Service Provider initiated flow). I would like to see IDP initiated flow working as well. @66c2a9d5cc86 

It's not working for our Organization.  Users within our organization are "successfully" signing into our IDP(Entra says Success) but getting an error message once re-directed back to our site saying something went wrong, try again later.

Is there an update on this?

Is anyone testing this in the EAP?

We are in the process of enabling SSO through Access for all the Atlassian products that we use. 

In addition to the users from our own domain, we also have several users from different domains. These users are either from our customers or vendors who access our own instance of Atlassian products to collaborate with us across several projects we work with them.

All of the users (from our own domain and external domains) are already federated to our identity provider instance. External users use their own domain email address as login to access the products that we offer them.

So, making this feature available or allowing a domain to be verified/claimed by multiple Atlassian instances (https://jira.atlassian.com/browse/ACCESS-1450) is a very critical one for us to continue use Atlassian products efficiently. When will make this feature to be available for us or General Availability to use? 

When will the EAP start? We need this feature urgently!
To be honest, I'm a little confused that this function isn't working yet!

Update as of February 2, 2024:
We are still on track to release this EAP to selected customers in Q1 2024 by March. Please keep posted for further updates and monitor your EAP tickets. ** 

If you are interested in joining this EUS SSO EAP please register your interest here. Please note we have limited space in the EAP and will be evaluating each customer who applies, we will notify selected customers by mid-February 2024.

This is planned as an enhancement to the external user security feature, wherein the currently supported method of 2FA is a one-time password (OTP) sent to external users via email. 

Hi,

any news? 

I submitted my request about EAP, but no feedback has been provided.

regards 

Leonardo 

Hello,

May we please have an update on the current status of development?

I've subscribed to the EAP, but what does this imply exactly? Does it mean we could have access to this feature before end of Q1 2024?

Many thanks in advance,

Sergio Guarino

Hi all!

Thank you for the continued feedback on this ticket! 

Our team is actively working on this feature and we are tracking towards our public roadmap item for an EUS SSO EAP in Q1 2024.

If you would like to be a part of the EUS SSO EAP please register your interest here: https://externalusersecurity.atlassian.net/servicedesk/customer/portal/3/group/4/create/10015

—

Additionally, as we develop SSO for EUS our team is beginning to look into further enhancements we can make for external user security. We would like to chat with organizations who currently use or plan to use external user security.

This is a great opportunity to help educate our roadmap, topics will include EUS security settings enhancements, EUS automation enhancements and EUS scalability enhancements plus anything else you have top of mind. 

If you would like to chat with the product manager for external user security please book some time with me here

If none of the times work please reach out to me at dolive@atlassian.com

All the best,
-David

Why can't the IdP tenant domain be trusted? For example, Entra ID guest accounts have a username that contains the tenant domain name @yourcompany.onmicrosoft.com. The email address value can be pulled from the claim if needed. 

Hi 14a97a75c29d , 

As indicated in my earlier comments, we are working on offering Atlassian Access customers the ability to enforce SAML SSO on external users (i.e. users from domains that are not verified under your organization). With SSO enforcement, the two-step verification controls would then be managed within your identity provider.

If you'd be interested in discussing your needs with regard to external user security in more detail, please email me at bnag@atlassian.com and I'd love to discuss this topic in more detail.

Thanks,

Bhavya Nag
Senior Product Manager, Atlassian Cloud

Our organisation is currently using 'Atlassian Access', early on we discovered the the following security controls are limited to only the 'verified domains':

1. SAML single sign-on
2. Password policy (inc basic things like strength and expiry)
3. Two-step verification

This means that for any users who's email domains we do not own (eg. external and third-party users accessing our site) we cannot apply even the basic security policies like password strength and expiry. Arguably these type of users (external and third-party) pose greater risk from organizational security perspective and control over these accounts is in fact more important than users on domains which we do own.

It seems Atlassian have decided that control of these accounts' security should rest with owners of each domain, totally overlooking the fact that these users are accessing our information, on our site (nothing to do with their email domain owners). We as an organization should have control over security for accessing out site for all accounts (not just users that are on our domains).

We would like to see this issue resolved by Atlassian, specifically all Atlassian security controls/policies should be made applicable to all all organisation users (including those on other domains), because ultimately those users have access to our information and thus we should have control over their accounts (not their domain admins, as stands currently, who are not accountable for protecting our organisation's information).

Hi 9c28c594ff0e,

I wanted to describe what the auth flow for external users would look like via an example. Let's say that xyz.com is a verified domain under your org and external users are from abc.com, this is how the external user auth workflow would work as part of the External User Security feature (which we recently shipped as part of an Early Access Program) once SSO enforcement is available as a method of 2FA:

• These users from abc.com will log in to their Atlassian accounts as they do today, subject to any authentication policies set by the admins of the org under which abc.com is a verified domain (not applicable if abc.com happens to be public email domain, of course).
• After they log in, before they can access your organization's content, they would be subject to 2FA controls which are enforced by your org's admins (i.e. the org under which xyz.com is a verified domain). Currently, the only supported method for 2FA is an OTP via email, but as part of this ticket we are exploring SSO enforcement for external users as an additional method in the future. With SSO enforcement, the MFA controls would then be managed within your identity provider. If I understood your message correctly, I believe this would meet your requirements.

If you'd be interested in discussing your needs with regard to external user security in more detail, please email me at bnag@atlassian.com and I'd love to discuss this topic in more detail.

Thanks,

Bhavya Nag
Senior Product Manager, Atlassian Cloud

We have similar situation. We onboard our external clients on azure AD as B2B or B2C guests. They use their own credentials to use our applications. For cloud, all incoming requests (regardless of their email domain) hitting specific org/site should be re-directed to primary claimed domains configured IDP page for authentication. Post authentication, policy set on Atlassian admin console should govern what happens next. I believe third party user access should be left to primary domain's IDP to decide what auth flow external users follow regardless of their existence in other orgs. Idea here is hard URL redirection to a company's IDP page instead of qualifying users email domain. This is also effective even when user is using public email addresses like Gmail, yahoo etc. 

9c6055eabfc9 - Addressing your earlier comment, once we support SSO as part of the external user security feature, the MFA enforcement settings you've set up within your identity provider will also apply for external users as part of their auth workflow. I hope this addresses your concern. Please reach out to me at bnag@atlassian.com if you have additional questions.

603e82128b56 - Thanks for sharing context on your requirements. We have started working on SSO enforcement for external users as an additional method of 2FA in the future for the external user security feature (that work corresponds to this ticket), which I believe will address your use case. We will update our Cloud roadmap when we have more information on the timeline for this capability.

From my understanding we´re in the same situation and require this feature to migrate to cloud. 

We have partners which are invited as B2B guests in our AzureAD. This AAD Guest login is already used for multiple other products like Zendesk, AWS services, Litmos, Business Central but will also work with on-prem products with an addon.

But with Atlassian Access it is not possible to make use of those accounts. That mean our partner would have to maintain another account and we have to manage accounts at multiple places. But with Atlassian access we tried to avoid multiple places to manage accounts. 

Hi Bhavya,

That is still a subpar, and actually unacceptable experience. If we have external users, like bob@abc.com federate into our identity provider, we are intentionally enforcing additional controls with our IDP. Your proposals would ignore those controls and allow the external users to bypass our controls.

Atlassian should, at worse, copy Github's approach with the shared identity across multiple tenants where the claimed domain can log in and then also choose to associate with this federated user from our IDP.

Thanks,
Andrew

Hi 0f77f0149368 ,

Leveraging your example of xyz.com being a verified domain under your org and external users being from abc.com, this is how the external user auth workflow would currently work as part of the External User Security feature (which we recently shipped as part of an Early Access Program):

• These users from abc.com will log in to their Atlassian accounts as they do today, subject to authentication policies set by the admins of the org under which abc.com is a verified domain
• After they log in, before they can access your organization's content, they would be subject to 2FA controls which are enforced by your org's admins (i.e. the org under which xyz.com is a verified domain). Currently, the only supported method for 2FA is an OTP via email, but as part of this ticket we are exploring SSO support for external users as an additional method in the future.

 
If you'd be interested in discussing your needs with regard to external user security in more detail, please email me at bnag@atlassian.com and I'd love to discuss this topic in more detail.

Thanks,

Bhavya Nag
Senior Product Manager, Atlassian Cloud

This will be a really good feature to support external users in one Atlasssian Cloud Organization. However, I would like to know if SSO is enforced for External users unclaimed domains in one Atlasssian Access Org. How would this work for these external users already have a claimed domain in their Atlasssian Cloud org. 

My org lets say claimed - xyz.com and external users in my org are from abc.com 

External org claimed abc.com in their Atlasssian cloud instance. 

Would this not be a conflict of Authentication policies between two claimed/verified domain Atlasssian Org's.