User Provisioning Design Questions

[Hunter Lardy]

I'm looking for some advice from the community on best practices for group management through Azure AD.

• Is Scenario 1 possible? 
• What are other people doing?
• What should I avoid?
• Where are some good resources? 

Below are three scenarios. In each, I did my best to draw what I think might be a viable design for group management. I'll explain them each below. 

Scenario 1

• User is in Azure AD group "Jira Instance B"
• "Jira Instance B" is synced with an Atlassian group of the same name. 
• The Atlassian group is assigned product access to Jira Instance B. 
• Admins add additional Atlassian (non-synced) groups to the user in Atlassian admin that provide additional Global Permissions etc. in the Jira Instance B site. 

I assume this is how most people are doing group management. 

That is, IF it's possible to manage non-synced groups through the Atlassian admin site. This part of the Understanding User Provisioning article makes me think it's not possible: Understand user provisioning | Atlassian Support . But I think that's ludicrous.

Scenario 2 

• User is assigned to the groups "Jira Instance A" and "Jira PM" in AAD. 
• Both groups are synced to groups of the same name in Atlassian admin. 
• User is assigned app access to Jira Instance A through one group.
• Assigned a Global permission set based on the PM role through the other group. 
• If User is added to another group "Jira Instance B" in AAD, they will be assigned app access to the other Jira site and be added to the PM global permissions set on that site. 

Is it good practice to have roles be independent of the different Jira sites? For instance, we would need Project Managers in every Jira site. Keeping them in one group would be clean. 

Scenario 3

• User is assigned the group "Jira Instance A PMs" in AAD. 
• Group of the same name is synced to Atlassian admin. 
• The Atlassian group provides app access to the Jira site and is included in the Global Permissions set. 
• Repeat for every different role for every Jira site. 

Each group has a green arrow that provides app access and a blue arrow that provides permissions. 

This would allow the most granular control but could be the messiest for Help Desk admins and require the most upkeep on the Azure and Jira sides. 

Pros and Cons

Scenario 1

• Would be the easiest for a Help Desk admin to manage. They would add a user to a Jira site in AAD, then a Jira admin would take care of the granular permissions.
• Would necessitate going to two apps to complete the job of providing access and permissions for any one user. 
• As syncs are on a 40 minute schedule in AAD, would have to come back to the job after switching contexts. 
• Least upkeep when adding permissions. 

Scenario 2 and 3

• If we're adding groups to Jira, we need the help of an AAD admin to build the group in AAD and sync it with Jira. 
  • Might not be an issue because we don't make new groups often. 
• Help Desk admins would have to keep track of a larger set of groups. Some people in one of our Jira sites are in 5 or more groups that provide different permissions. 

Conclusion

How should I weigh these different considerations against each other? What do other people do? 

Are people using attributes scoping for group management? 

Is Scenario 1 possible?!?!?!

[Amaresh Ray – Multiplier]

@Hunter Lardy sharing some of my thoughts here, hope this is helpful:

Is Scenario 1 possible? Unfortunately, no. Once you enable SCIM provisioning, you can only manage groups that are synced from your identity provider. You lose the ability to manage groups directly in the Atlassian admin interface for provisioned users.

Recommended Approach: 

After reviewing your scenarios, I'd recommend Scenario 3 for maximum flexibility and control, but pair it with a tool like Multiplier to eliminate the administrative overhead of adding/removing users from the individual groups in AAD.

Why Scenario 3 + Multiplier Works:

Scenario 3 gives you:

• Maximum granular control per site/role combination
• Clear separation between instances
• Easy auditing and compliance
• Futureproof as you add more Jira instances

Multiplier solves the overhead problem:

• Self-service access requests through JSM
• Automated Azure AD group assignments - no manual group management
• Approval workflows for governance
• Zero context switching for Help Desk - everything stays in JSM

Your Help Desk team never touches Azure AD directly - users request access through JSM, get approvals, and Multiplier handles all the group assignments automatically.

[Hunter Lardy]

Bump! 

Starting conversations with our Azure admins soon. I'll update this post with the solution we implement. Maybe it will help out future generations. 

Appreciate any insight y'all community members can provide.