Provisioning groups from custom IdP

[Jeffrey Anderson]

We use Atlassian Access with a custom IdP proxy running simplesamlphp, which proxies through to a federated login.

Since this is an IdP proxy, I don't think we can just sync the users and groups over, as a valid user has to authenticate against a federation.

But we do provide group information in the SAML assertions sent by our IdP.  

What do I have to do to integrate that group information with Confluence?  We provide a list of groups under the 'groups' attribute.  Is it sufficient to match the names of these groups with Atlassian groups?  Or do I need to modify the group attribute name in some way?

[Jeffrey Anderson]

Thanks, this is useful.

I have a question though.   I've managed to create some groups via the SCIM API.  We also have managed users, but those users were created through JIT provisioning and don't show up when I query the directory via the API.  It seems that they do not have a "value" attribute, which is necessary to add them to managed groups.  

I'm wondering what I can do safely.   The accounts exist and can be used, but are not marked as "synced" users.  That much is ok, but is it possible to use SCIM to make those users members of managed groups?

I guess this is some sort of hybrid use of the managed directory that was not intended.  It seems that you expect the users to be provisioned in one step from the IdP, which is not how we have done it.

Jeff

[Jeffrey Anderson]

I intended this as a question to Dave's answer, not as an answer to my original question.

[Dave Meyer]

Hey @Jeffrey Anderson ,

If you sync a group via the SCIM API with a user that has the same email address as an existing managed account, the profile details from the SCIM push will overwrite the existing profile attributes of the account, and the account will be treated as managed externally and they will have membership in whichever external groups you've synced.

I think this is what you want and it's a fairly common scenario. Most customers have a number of existing accounts (either created directly with Atlassian and then having SAML SSO enabled later, or created with JIT provisioning with SAML). Hopefully this makes sense.

[Jeffrey Anderson]

OK, I think that is what we want.

If you  could just clarify one thing --

at  https://developer.atlassian.com/cloud/admin/user-provisioning/rest/api-group-groups/#api-scim-directory-directoryid-groups-id-patch

there is an example of updating group membership.  It seems that users have attributes "display" and "value" where value is some UUID sort of thing.  How do I find out the "value" for my existing users?   

[Dave Meyer]

Hi @Jeffrey Anderson ,

Sorry for the delay in getting back to you. I think the value should be the `id` in the Get all users method https://developer.atlassian.com/cloud/admin/user-provisioning/rest/api-group-users/#api-scim-directory-directoryid-users-get

[Jeffrey Anderson]

Hi Dave:

Yes, no doubt that is true.  But I've found that users created via JIT provisoning do not appear under the "Get all users" method.  So if they have an 'id', I'm not sure how to retrieve it.  These JIT users are listed as managed, but not as synced.

In any case, we've decided to abandon JIT provisioning and create all our users from the start, so I don't think it will be an issue going forward.

No doubt these issues arise from an unusual setup.  

[Dave Meyer]

Interesting. I think that the `account_id` attribute that you'll get from this API (https://developer.atlassian.com/cloud/admin/organization/rest/api-group-orgs/#api-orgs-orgid-users-get) will be the correct id, but I wasn't able to test it to verify. Note that that API takes a different token than the SCIM API 

[Jeffrey Anderson]

I'm just returning to this question after getting distracted with other things.

It seems that "account_id" is not the same as the "id" needed to add users to a synced group.  I think this is because "id" refers to membership in a specific directory.   

I can view all users via the organizations API as you suggest.

Apparently users who are provisioned via JIT do not get added to the synced directory.   Therefore they don't get a directory id, and cannot be added to synced groups related to that directory.  I see that my pool of "managed users" is less than the number of users belonging to my managed directory. 

I wonder if there is any way to merge these stray users into the synced directory.  The accounts already have emails in my validated domain.

[Dave Meyer]

Hi Jeffrey,

I reviewed this with our engineering team, hopefully these instructions make a little more sense:

• Users created through user provisioning will have two associated ids: id and an Atlassian account id.
  • Id refers to the user id in the user provisioning directory and is used by the identity provider to update the user via user provisioning.
  • Atlassian account id is the account id of the Atlassian account associated with the user synced through user provisioning.

In order to get the JIT-created users into your SCIM directory you would need to create accounts through the user provisioning API with the same email address (this is the primary identifier for accounts). The user created through user provisioning will be linked to the existing Atlassian account with matching email on creation. At this point, they should appear in the SCIM directory and you can manipulate them.

[Jeffrey Anderson]

Thanks.  That's very helpful.

I was afraid to re-provision the existing JIT users because I thought it may interrupt their existing accounts.

I'll give it a try.

[Dave Meyer]

Hi @Jeffrey Anderson ,

You can use our SCIM API to send group information and updates and have them synced to Atlassian (and groups will be synced to your Confluence site assuming it's linked to your organization with Atlassian Access).

Check out:

https://confluence.atlassian.com/cloud/user-provisioning-959305316.html

https://developer.atlassian.com/cloud/admin/user-provisioning/rest/intro/