Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,467,470
Community Members
 
Community Events
177
Community Groups

Atlassian identity migration to SSO

Edited

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

 

1 answer

0 votes
Dave Meyer Atlassian Team May 10, 2021

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

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 Atlassian Team May 13, 2021

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

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 Atlassian Team May 14, 2021

@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.
Like Arun Gupta likes this

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events