Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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
Community showcase
Published in Atlassian Access

Resources + Q&A from "What's new in Atlassian Access" webinar

Hi Community! Thank you to all those who joined our What’s new in Atlassian Access webinar last week! We received so many great questions about existing functionality and newly released features of...

776 views 0 7
Read article

Community Events

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

Events near you