Atlassian identity migration to SSO

Question

Hi, We are currently using Atlassian cloud - JIRA and confluence and we have standard users using their email and password to login. We have some internal users as well as external users. For example

Internal Users - user1@mycompanydomain.com.au

External Users - user2@externaldomain.com.au

We want to move the authentication to Azure AD using Single Sign on. As i understand so far, we will need to

1. Verify the domain (mycompanydomain.com.au)

2. Create the Atlassian cloud application in Azure AD and exchange SAML metadata.

3. Create users and groups in Azure AD and assign it to the Atlassian Cloud application in Azure AD

4. SCIM provisioning of users from Azure AD to Atlassian cloud.

The questions I have is:

Q1. We currently have multiple confluence pages, workspaces, JIRA boards, etc. How will it impact the users when we move from Standard Credentials to SSO ?

Q2. Is it correct understanding that the authentication is managed via SSO, however authorization is still managed via Atlassian cloud ?

Q3. we currently have multiple groups in Atlassian. For ex. groupA_internal, groupB_internal, groupC_external and so on. When we move to SSO, How would Atlassian know that the users in groupA_internal to use the same level of permission to confluence/JIRA that it has as part of the same credentials? Is there any mapping required to be done in Azure AD?

Q4. There are few users (at executives level) who has access to certain confluence pages, which others don't have. will there be any impact to them ?

Q5. When a new user is added to Azure AD group that is assigned to Atlassian application, what level of access the new user will have ?

Q6. once we cut over to SSO, how do we remove the standard login method?

I am doing similar set up

https://community.atlassian.com/t5/Atlassian-Access-questions/Existing-Users-When-Moving-to-Atlassian-Access-and-SSO/qaq-p/1308240

Dave Meyer · Answer

@Arun Gupta

Yes. Your Jira and Confluence site can have both internal and external users. The internal users will log in to their accounts using the Azure AD SSO policy that you define, while the external users will continue to login with their own credentials. Nothing about their login experience would change.

> Can I assume I can move few users initially to SSO and leave the rest of the users to Standard credentials to test if everything is working okay and then if everything is fine, them move everyone to SSO (except external users)?

Yes, this is one of the intended use cases for the authentication policies feature.

> Currently we have a challenge that when we add an external users, he gets access to all the spaces / project in JIRA and confluence. We also need to solve this problem to ensure least access of privilege to the team members. How can this be solved using Atlassian Access ?

You don't need Atlassian Access to solve this. What I would recommend is that you:

* Review your default groups. These are groups that all users are added to when they are invited to your site, depending on which products you assign them to.
* Update your Jira permission schemes and Confluence space permissions (or at least, the default permission scheme and default space permissions) not to use the default groups. This will prevent new users from automatically being added to all projects and spaces.
* Create a dedicate group (or groups) for your guest users. In Jira, you can create a separate permission scheme where that group has access and use it only for the projects you choose, while using a different scheme where that group has no access for the rest. In Confluence, you can grant that group access to the right spaces on a space-by-space basis. For Confluence specifically, we will be launching more advanced external collaboration features later this year.

Arun Gupta · Answer

Thanks @Dave Meyer

To my 3rd question above, as I mentioned that I have both external users and internal users, is it possible to manage my internal users via Azure AD and external users via Standard credentials at the same time ?

Also, as you mentioned as soon the users are assigned to an authentication policy, they will automatically move to SSO. Can I assume I can move few users initially to SSO and leave the rest of the users to Standard credentials to test if everything is working okay and then if everything is fine, them move everyone to SSO (except external users)?

Currently we have a challenge that when we add an external users, he gets access to all the spaces / project in JIRA and confluence. We also need to solve this problem to ensure least access of privilege to the team members. How can this be solved using Atlassian Access ?

Dave Meyer · Answer

@Arun Gupta if you have an active Atlassian Access evaluation license you should be able to to contact our support team via support.atlassian.com

There are detailed instruction guides depending on your identity provider, we have links to the major ones here: https://support.atlassian.com/security-and-access-policies/docs/configure-saml-single-sign-on-with-an-identity-provider/