Provisioning groups from custom IdP

Jeffrey Anderson November 23, 2020

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?

2 answers

0 votes
Jeffrey Anderson November 29, 2020

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 November 29, 2020

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

Dave Meyer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
November 29, 2020

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 November 30, 2020

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
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
December 6, 2020

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 December 6, 2020

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
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
December 9, 2020

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 January 17, 2021

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
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
January 19, 2021

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 January 19, 2021

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.

0 votes
Dave Meyer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
November 28, 2020

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/

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events