SingleSignOn: Can we setup multiple Atlassian Cloud Instances that authenticate to the same domain?

[Jackson Lum]

Hi, we are an organization that has multiple entities sharing the same domain in active directory. Some entities want to setup Atlassian Cloud instance that is only for the use that entity. However, all these entities are interested in using Single Sign On with the same domain. From my research, Atlassian Access is needed for Single Sign On. There is a discussion on Verifying a Domain.

My question is: can we setup multiple Atlassian Cloud Instance that all authenticate using the same domain? For example, we would like to have ACME1, ACME2 and ACME3 Atlassian cloud instances, but everyone has an email address of XXX@ACME.COM.

[Jackson Lum · Accepted solution]

Hi Ian,

I wonder if dept1 can purchase and own the Atlassian Access subscription at first. Then when other departments are interested to subscribe to to Atlassian Cloud products, then discussion of moving the Atlassian Access to central authority can be had. @Rodrigo B_, do you see this scenario working?

[Rodrigo B_]

Hey @Jackson Lum and @Ian Walsh,

Yes and big no, the big no is because if other departments are using Jira or Confluence as well, they will be forced to use SSO without their acknowledgement, because they would be under the same verified domain probably, so it will raise some confusion.

Yes goes for when that is the only department using Atlassian services or if that department has a subdomain, let's say dept1.university.edu, this way you only have that department's users domain verified and being forced to the SSO.

Rodrigo Becker
Atlassian Cloud Support

[Ian Walsh]

Interesting!

So if a department has dept1.example.edu they could verify only that domain and use that with Atlassian Access?

Does that mean the email addresses would have to end in @dept1.example.edu as well?

[Rodrigo B_]

Hi @Ian Walsh,

Yes, otherwise Jira/Confluence notifications would go nowhere and also, if the user sends an email to the project email to create an issue or comment, it would not be accepted as the email from the sender would not match any email with the proper permissions on the instance.

RB

[Ian Walsh]

In our case almost all email addresses are scoped to the @example.edu domain even though the department owns and can validate dept1.example.edu and they use that domain for their website.

It sounds like that means we cannot use the sub-domain method.

[Rodrigo B_ · Accepted solution]

Hello @Jackson Lum,

Welcome to our community!

Answering your question, yes, you can have multiple instances authenticating to your Single sign-on (SSO), this happens because you will have an Atlassian organization which is a global entity, once you verify a domain, all existing Atlassian accounts that have their emails verified will become owned by your Atlassian organization and will run under your configured security policies, an SSO, for example, this policy is enforced on the Atlassian account no matter which Atlassian service the user is authenticating (Your ACME1, ACME2, ACME3 and even Atlassian Community).

This integration is done by creating the Atlassian organization, verifying a domain, subscribing to Atlassian Access then configuring the SSO integration via SAML, the following documentations will help you on that:

• Organization administration
• Domain verification
• Single sign-on with SAML

Let me know if you still have any questions!

Best regards,

Rodrigo Becker
Atlassian Cloud Support

[Jackson Lum]

Thanks for your response Rodrigo!

Just to clarify what you said:

1) The Atlassian organization will be ACME.

2) Then we can have ACME1.Atlassian.com and ACME2.Atlassian.com and ACME3.Atlassian.com instances.

In terms of payment, ACME1 wants to pay for their own licensing, ACME2 wants pay for their own licensing etc. Is that possible?

I think the preference would be for ACME1 and ACME2 and ACME3 to have their own organizations, but they share the same domain. Is that possible?

[Rodrigo B_]

It's not possible to share the same domain, a domain can only be claimed by a single Atlassian organization.

The billing and licensing works this way, each instance has it's own billing, for Jira or Confluence, etc, an Atlassian Access subscription is also a separate licensing/billing, so it would look this way:

ACME1 - Paid by ACME1 group

ACME2 - Paid by ACME2 group

ACME3 - Paid by ACME3 group

ACME Org with Atlassian Access - Paid by the 3 groups

If you have a cost center problem behind it, it may be difficult to share the expenses between the 3 groups, currently we have a feature to allow administrators to generate a CSV from the Atlassian organization managed accounts page, this would allow you to see to which instance an user participates:

• https://jira.atlassian.com/browse/ACCESS-44

The feature is under development, so it's not available yet, but once it is, you would be able to export the CSV and separate the users to share the expenses.

Thank you & best regards,

Rodrigo Becker
Atlassian Cloud Support

[Jackson Lum]

Thank you Rodrigo, that is really helpful information.

[Rodrigo B_]

No problem @Jackson Lum, happy to help! If you're good, just make sure to accept the answer so others in the community can see it had a solution and benefit as well!

Rodrigo

[Natalia Lezhai]

Hi @Jackson Lumand @Rodrigo B_

So according to this: is it possible to have two organizations created in Admin? 

[Rodrigo B_]

Hi @Natalia Lezhai,

Yes, per limitation, the second org will have to be created by an user that is not an org admin already and is a site-admin on any Cloud site, but once the org is created, the org admins from the other org can be added to the second one as org admins as well, if required.

Kind regards,

Rod

[Daniel Yarmoski]

So is the answer to this no.  It is not possible to connect multiple atlassian cloud instances ab123.atlassian.net and abc1234.atlassian.net to the same abc.com domain.  Meaning one or the other can use sso for abc.com.  The users at abc123 instance would get in fine.  While the people at abc1234 would get redirected by ad but get error messages.  Am i correct in saying this?

[Ian Walsh]

I work in an organization with a fairly delegated management structure. Our users are in a central email domain (example.edu, let's say).

We have departments who manage many of their own IT systems but use the university system for user authentication and email services (dept1 is one of them, let's say).

dept1 would like to purchase Atlassian Cloud with Atlassian Access. They are basically an independent entity purchasing and supporting this system but are relying on the central university systems for authentication with Atlassian Cloud and email.

Your example suggests that some central authority at example.edu would need to purchase and administer Atlassian Access and then use that administration ability to delegate separate groups within the example.edu Atlassian Access tenant to dept1.

Do I have that correct?

If so, you should know that limitation may make implementing Atlassian Cloud/Access not feasible for a significant number of possible customers. For us, this may be a barrier too large to overcome.

[Kevin J Karasinski]

I think the need is only authorization. If group and roles need to be managed with JIRA does that change anything?