Multiple identity provider support now available in Cloud Enterprise

[#1]

Hello Atlassian community!

My name is Sandy and I'm a Cloud Trust product marketer, focused on Security. Our team is super excited to share that after a 3-month Early Access Program (EAP) with 17 enterprise customers like yourself, we are now launching multiple identity provider support as generally available in the Cloud Enterprise edition!

Prior to this, customers with Atlassian Access or Cloud Enterprise were only able to connect a single identity provider to implement SAML SSO and SCIM user provisioning to their Atlassian Cloud organization. Today, Cloud Enterprise customers can connect multiple identity providers, which empowers admins to:

1. Quickly consolidate user management of an acquired company's identity provider within the parent company
2. Maintain separate identity providers for separate departments' domains within a company
3. Meet certain data residency requirements where each region needs its own identity provider

Beyond supporting multiple identity providers via the SAML/SCIM protocols, we also introduced several new capabilities to help enterprise administrators:

• Set a default authentication policy as non-billable, when not synced with an identity provider
• Connect a Google Workspace and multiple identity providers via SAML/SCIM
• Link a domain with an identity provider to manage which authentication policy new users land in

For more information about how to connect identity providers to your Atlassian Cloud organization, take a look at our documentation. If you're just getting started with your Cloud Enterprise plan, have a look at our guide here. 

Are you as excited about this feature as we are? Did you find this information helpful? Please share your thoughts below – we'd love to hear from you! Be sure to take a look at other community members' comments/questions and up-vote those you find interesting.

[Mike Rathwell]

Do you know when we might start to see this roll out to production, @Sandy ? I just looked at two of my orgs and neither of them have that yet. In one of them, it would be so, so helpful; G-Suite groups are rather better organized than the dumpster fire that is Okta. It would be nice to leverage that.

[Sandy]

Hi @Mike Rathwell we appreciate the enthusiasm! We are currently rolling it out so you should see it in your cloud organizations by the end of this week.

[Mike Rathwell]

That is awesome @Sandy ! I will watch for it and start reading docs on it here. Is there a link to "official" docs for this enhancement yet?

[Taranjeet Singh]

That's a piece of great news! This is going to be a very useful feature for Cloud Enterprise customers.

Thank you @Sandy for sharing the news and the high-level details and benefits of the feature

[Dirk Ronsmans]

Great news @Sandy !

I'm wondering tho, will this also trickly down to Premium customers with Atlassian Access?

[Stefanie Sullivan]

Do we know if it still requires one Atlassian instance to claim each domain?

It seems like this is saying that we can now set up SAML from both COMPANY A and COMPANY B to our single instance, but it’s not clear that it will allow us to set up domain COMPANY B  with their own Atlassian footprint (and Atlassian access) to use SSO into our tenant while retaining control and ownership of their domain to sign into their tenant.

[Craig Nodwell]

Been waiting for something like this.

[Ben Magro]

@Dirk Ronsmans 

We made the decision to not bundle security-related features in Standard and Premium product editions. This means customers on either standard or premium can purchase Access if they require our standard security features like SSO and Audit Logging.

Anything that fits into the more Advance category of security features like Multiple Identity Providers will be packaged in our Enterprise edition as we believe this edition is the best fit for those customers.

I know this is not ideal to hear for some customers, but the decision was not made lightly. 

Ben Magro

[Ben Magro]

@Stefanie Sullivan 

We still require a domain claim in order to manage accounts. We have another solution that will allow external users to require 2fa coming in the future.

[Alexander Post [venITure]]

@Sandy We really like this feature. It might be beneficial to have this feature for non Enterprise Customers too. In Germany we find a lot SME which have not an enterprise plan or are to small to buy the enterprise plan. But these customers need this feature too. 

Otherwise its very complicated to explain the customer why they need to buy Access for SSO and also a Enterprise Plan to Upgrade Atlassian Access. This is complicated and as described above does not cover all customers. 

Maybe you can add this to Access by default or allow smaller customers to buy this feature. 

[Stefanie Sullivan]

@Ben Magro Will this solution be available for all customers or only Enterprise customers?

[Ben Magro]

@Stefanie Sullivan As stated above. Only enterprise customers.

[Barry Vercueil]

Hi @Ben Magro

This is disappointing that this feature is only available to Enterprise customers, especially taking into consideration that the initial feature request was initiated from my team. and we were granted early access (albeit it never worked). 

I would like to understand why this feature is only made available to enterprise Customers, as we are a relatively large Atlassian consumer and we are desperate need of this functionally. We face the reality of deleting our AD Identity provider in sacrifice of another important initiative.

I look forward to your feedback.

CC: @Jaco Becker @Marco Silva 

[Fabrice Huart - NSI]

Hi @Ben Magro ,

I share the opinion of other members here.

This feature is mandatory for a lot of companies that don't need all the features of Enterprise licenses. Adding this at least in Premium plan is fore sure a must have if we want to move smoothly from Server to Cloud in a lot of cases.

Available to discuss this more in details with you for uses cases.

Best regards,

Fabrice

[Chris]

Can Atlassian please sure the reasoning behind this decision?

We have 25 people in another Azure AD tenant and asking us to pay for an enterprise subscription just for this is pretty ridiculious. We have zero use for all the other enterprise features, we just need these people to be able to sign in via AAD.

[Rex]

How are accounts consolidated when the same email exists in multiple IdPs when multiple IdPs are connected? Does the account added first or later get priority? Or are they aggregated or handled in some other way?

[George Ribeiro]

Can you confirm if this will work with multiple domains under one domain in Atlassian with Atlassian Enterprise using different SSO for each domain. Like Google, Google MFA, AD Ping

[Jan Odvárka]

Can we expect any change of direction in possibilities to ad more tha one IDP for premium instances?

[홍권혁]

Hello,

I'd like to make sure that multi-AzureAD integration is possible.
I would like to connect Alpha AzureAD, Beta AzureAD, and Gamma AzureAD into one organization.
We would like to integrate the ADs of several companies and collaborate in one organization.

Azure AD Sync is required when each Azure AD is linked.
What I set up is added only as DNS domain when additional AD interworking after one Azure AD setting.

[Vedant Kulkarni]

is this still possible now with Atlassian Guard? - Connecting A AzureAD, B AzureAD, and C AzureAD into one organization.

[Dirk Ronsmans]

@Vedant Kulkarni  It's definitely possible but only with an Enterprise subscription

[Vedant Kulkarni]

@Dirk Ronsmans Thanks.

Moreover, is it possible to configure multi IDP with multiple SSO providers such as:

AzureIDP-AzureSSO-Domain1

OktaIDP-OktaSSO-Domain2

OneloginIDP-OneloginSSO-Domain3

[Dirk Ronsmans]

Yes, but also only with a Enterprise subscription as that is the prerequisite to having multiple IDP's configured at all

[Rex]

@Dirk Ronsmans 
I see that you have a lot of experience with multiple IdP integrations. I understand that if an account with the same email is already linked to an IdP, it is not possible to link additional IdPs. Have you ever encountered this issue and have you solved it?

[Vedant Kulkarni]

@Dirk Ronsmans thanks for the response.

@Rex, yes I have a similar problem statement with the group: How will agent logins/product association be handled if same-name groups are present in multiple IDPs?