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?
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.
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.
OK, I think that is what we want.
If you could just clarify one thing --
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?
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
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.
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
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.
I reviewed this with our engineering team, hopefully these instructions make a little more sense:
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.
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).
Did you know Atlassian Access offers more than SAML single sign-on for Atlassian cloud products, like Jira and Confluence? Whether you're just starting to plan for your organization or in the pr...
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