Best practice for managing multiple departments sharing a single SSO domain

[Alan Farkas]

I'm a little confused over thepurpose of an Atlassian organization and how an organization relates to a company domain.

Both my department and another department within my company plan to use Jira & Confluence in a new Atlassian Cloud instance. We will be only supporting SSO users.

I would like to be able setup a scheme where each department can create, control & setup access to their own Jira apps and Confluence spaces without having access to the other departments Jira apps and confluence spaces. The access would be granted using Atlassian security groups.

Also, it's possible that the same user will need to access Jira/Confluence apps/spaces across more than one department.

What's the best way to accomplish all this?

Does is make sense to create an Atlassian Organization for each department? 

Can more than one Organization both share the same SSO domain?

I'm not sure that I completely understand the concept of managed users. Can more than one organization assign security to the same SSO user?

I read online that a managed user can only be claimed by a single organization. Do I need to claim a user in order to add them to a security group and/or change their security access?

[Craig Castle-Mead]

Hi @Alan Farkas 

I would recommend one Atlassian org to manage the authentication of users (required at the moment as access only supports a single org to claim a domain, but as @Aneita @mentioned, they’re looking to release support for one domain to be split over multiple orgs). The management of the users and authentication policies does not necessarily have to relate to how the products are used (managed and billed) though, so my suggestion is (given your stated requirement that each department can manage (admin/billing) of their products:

- one org that manages your entire domain and its SSO. Users would have to be granted access to this org to login to anything within the Atlassian Cloud world. This org would get the bill for the SSO/SAML component. 
 - one org for each department. These orgs would not manage your users/saml, but the products (Jira/conf/etc) related to their department. As product admins for all products within their org, they would be able to assign users (from the central org) to their products, and would be billed for those products. 

CCM

[Aneita]

👋🏼 Hey @Alan Farkas

Aneita here - I'm a product manager on the Atlassian Access team. 

By verifying a domain, you are able to manage users with Atlassian accounts on the verified domain. By managing users, you can then enforce authentication policies on the managed users (e.g. SSO, 2FA, session timeout etc), or have visibility into shadow IT. For example, if you verify the acme.com domain, you can then require that everyone using Atlassian products with an acme.com email address log in via your SSO provider. 

Today, a domain can only be verified by one organization which means only one organization can enforce authentication policies on users. This is something we are actively working on removing as a limitation. Soon (by March 2024), multiple orgs will be able to verify the same domain, and each manage their unique subset of users.

A user can only be managed by a single organization, and only the org that manages them will be able to assign an authentication policy for the user. 

Whether you choose to set up a single, or multiple, Atlassian orgs is up to you but keep in mind that for the time being, only one org can verify a domain. 

A single Atlassian organization might work better in situations where the administrator(s) of the Atlassian products are the same for the different departments (e.g. where there is a central IT team to administer products). 

You might want to consider multiple Atlassian organizations if you prefer independent administration and billing of the products (e.g. if the departments using Atlassian products are totally independent of each other). 

Regardless of which option you choose, it won't impact your users' ability to access products in another department or organization. Product access is controlled by invitations/product permissions, and users can still be invited to collaborate in a different organization. 

Hopefully this information helps. If it'd be useful, I'm happy to jump on a call to help discuss things further too. 

Cheers,

Aneita