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.
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?
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.
Atlassian Cloud Support
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.
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:
Let me know if you still have any questions!
Atlassian Cloud Support
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?
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:
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,
Atlassian Cloud Support
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.
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?
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.
Did you know Atlassian Access offers more than SAML single sign-on for Atlassian cloud products, like Jira and Confluence? Whether you're just starting to plan for your organization or in the pr...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events