SAML Configuration

[Kevin Dietz]

If I create the SAML configuration and also configure my Azure Atlassian Cloud app for just 1 user in my Azure AD domain, will all of my remaining Atlassian users who have not been assigned to the Enterprise app still have the normal Atlassian access. I want to test SSO with 1 user without breaking access for all.

[Dave Meyer]

Hi @Kevin Dietz,

Unfortunately this won't work – once you enable SSO for your organization, it will apply to all accounts on any domains you have claimed.

What we recommend is first verifying a subdomain (like test.yourdomain.com, or just another domain entirely), then setting up a user in Azure AD on that subdomain, then go ahead and configure SAML SSO with Azure AD and test it out with that dummy user. Then you can simply claim your production domain on the Atlassian side and your SAML SSO configuration with Azure AD will automatically apply.

We know this is a bit clunky and we are planning work in the future to simplify the testing process.

[ramani_chandran]

Hi @Dave Meyer ,

We are using a test cloud instance to test our AD integration ,Even if we use our production domain to verify in that test instance,  the production users wont get affected right. Since they dont have access to the test Environment. Correct me if I am wrong.

[Dave Meyer]

Hi @ramani_chandran ,

No that's not correct. Regardless of whether you have one or more products linked to your organization, your SSO configuration applies to all Atlassian cloud tenants and services because it's tied to users' Atlassian account, based on the domain you have verified. The domains you verify are not scoped to any single instance.

[ramani_chandran]

Hi @Dave Meyer ,

Thanks for your reply. Can you please correct my understanding.

we are using a trial free version of cloud ( tenant - jiratest.atlassian.net ) and i have verified a domain called ex. abc.com.au and claimed all the accounts under that domain. so here the AD integration will be tested for jiratest.atlassian.net tenant only. So still the users will get affected right, since they are part of that domain.

[Dave Meyer]

Hey @ramani_chandran ,

It's only based on the domain, not based on the tenant. So if you have only verified ex.abc.com.au and configured SSO, it will apply to all users with an @ex.abc.com.au email address, regardless of whether they are accessing jiratest.atlassian.net, jiraprod.atlassian.net, or even this site (Atlassian Community). When you verify the actual abc.com.au domain, your SSO configuration will start applying to all @abc.com.au users across all those sites as well. Does that make sense?

[ramani_chandran]

Yes @Dave Meyer that makes sense. Thanks for your inputs.

[ramani_chandran]

Hi Dave,

Another one question came up in my mind, If a user with email abc@vodafone.com.au  is accessing the test tenant url (jiratest.atlassian.net) in which the production domain(vodafone.com.au) is verified, but he wont be having access to that test tenant right. Then can you please advise in which way the user get affected in terms of authentication.

Note: we planned to integrate our trial cloud instance with our organization ADFS.

[Dave Meyer]

Hi @ramani_chandran ,

It's important to understand that when you verify your domain and configure SSO, this applies across all tenants. The domain verification is not specific to any one tenant.

The reason we've designed our system this way is to help you get full visibility into Atlassian usage in your organization. If users are working in tenants that you don't happen to manage or know about, you can be assured that they will still be covered by your SSO configuration and that you'll have some visibility into what tenants they're accessing.

So naturally another consequence is that enabling SSO does not affect which tenant a given user actually has access to. So if the user already has access to the test tenant in your case, then enabling SSO will change how they log in, but they will still have access. Conversely, if they do not have access, then enabling SSO will not grant them access.

We do support granting automatic user access from identity providers via our user provisioning feature, but this is currently only supported for Azure AD, not AD FS. So I expect you would be adding and removing users to your site directly (https://confluence.atlassian.com/cloud/invite-and-remove-users-744721624.html)

Hope this helps.

Dave

[ramani_chandran]

Hi @Dave Meyer ,

Thanks again. gives more clarity.