Atlassian identity migration to SSO

[Arun Gupta]

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]

Hi @Arun Gupta 

> 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 ?

Enabling SSO only affects users' login experience. There is no impact to user's actual permissions/authorization within the product or association between users and data.

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

If by "authorization" you mean which users and groups have access to the products and their permissions within the products, then yes. You can update the membership of groups via SCIM provisioning, but the permissions for those groups are defined on the Atlassian side.

> 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?

If you sync groups that have the same name as existing groups you have within Atlassian, you will be presented with the opportunity to let Azure AD become the source of truth for those group memberships or change the name and create new groups instead. See the docs here: https://support.atlassian.com/provisioning-users/docs/resolve-group-conflicts-when-syncing-users/

> 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 ? 

As mentioned, as long as access to those pages is based on individual users or the groups that define permissions for those pages do not change, then there will be no impact (except for the fact that they will log in with SSO)

> 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 ?

They will have permissions based on whatever group they are a member of. As a starting point, you can look at your "product access groups" but it will also depend on how groups are used in permission schemes in Jira or permissions in Confluence. https://support.atlassian.com/user-management/docs/update-product-access-settings/

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

As soon as users are assigned to an authentication policy that is enabled and has SSO, they will automatically started logging in with SSO on next login. There's no manual cutover. 

Hope this helps,

Dave

[Arun Gupta]

Thanks @Dave Meyer for your prompt response.

Is it possible to engage Atlassian during our migration as I have some more clarification required.

Also, is there any documentation that include the steps for moving to SSO?

[Dave Meyer]

@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/

[Arun Gupta]

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]

@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:

1. 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.
2. 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.
3. 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.