Azure AD SCIM User Provisioning Question

Question

Hello all!

We're migrating our on-prem JIRA and Confluence server instances to Cloud.

While setting up Atlassian Access, upon verification of our domain, I have a bunch of managed accounts present. (great, but not quite what I want long term)

We've set up SAML SSO with O365/Azure AD successfully (cheer). For the couple of test users who've tried it out, this is working as expected.

I'm now working on SCIM user provisioning (from the same Azure AD to the same Enterprise App as used for SAML).  My questions are with adding scoping filters.  Or - maybe there is some other means besides scoping filters to accomplish the following?

* Can I scope to provision users from a specific OU rather than syncing everything from Azure AD into Access? * If not, and I have to use one of the listed attributes, I'm curious as to which you're using for your envrionments (hoping inspiration strikes from your suggestions)

* Same question for group provisioning. We'd like to sync the groups in a specific OU only, and not ALL of them in our AD.

Thanks in advance for you help and insights!

Jennifer Osborn · Answer

Thanks for the response.  So what I'm hearing is, we need to use groups.  There isn't a means to pull from an OU (because the traditional OU structure doesn't exist in Azure AD).

I appreciate the support for the recommendation to use a second app instance.  Now to figure out how to remove the provisioning from the SSO app.

Ed Letifov _TechTime - New Zealand_ · Answer

If you configure your Atlassian Cloud Enterprise Application to "Sync only assigned users and groups" (a drop-down in Manage/Provisioning/Edit Provisioning/Settings) it will only sync individual users and users from groups you assigned to the application in Manage/"User and groups".

It will also sync only groups listed there i.e. if you had a user who is a member of 30 groups, but you assigned only 1 group out of these to Atlassian Cloud – only this group will be synced.

This is why it is recommended to have 2 instances of Atlassian Cloud application - one for SSO, where the assigned groups define who are allowed to do SSO into Cloud, and the other for Provisioning, where the assigned groups get synced with the users who belong to them and can be used for more fine-grained permissions inside the Cloud applications.

Obviously you'd want to have all groups set on the SSO-related application to be in the list of groups set on the Provisioning-related application, but possibly not the other way around.