1
votes

Specifically, can SCIM be used to add Users to pre-existing (non SCIM-created) groups? We need to provision users via SCIM, but then add them to Groups created manually in the site (a .Net application).

As I understand it, it can't be done like this. Group Update requests (i.e. PATCH requests) seem to require the "id" attribute as the unique identifier for the group, and this "id" seems to be only generated in SCIM Create Requests. So if a Resource (Group / User) wasn't originally created via SCIM, SCIM can't update/replace/delete it. Is that correct?

e.g. PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce

I thought about a workaround convention, such as using "user:1234" and "group:1234" as the "id" attribute format (i.e. [resource type]:[internal type-specific ID]), and then any User or Group can be specified by "id", even if it wasn't created via SCIM. But that seems pretty hacky.

Is there a better way of doing this? Many thanks for any help, very new to SCIM!

1

1 Answers

1
votes

Yes, SCIM can be used to manage "brownfield" scenarios where existing non-SCIM created objects exist.

Typically the logic flow that happens for a user object is:

  • GET on /users with a filter (as defined in RFC7644 3.4.2.2) using an attribute that is uniqueness constrained (such as userName, email).
  • If no user found matching that criteria, create a new user with POST to /users
  • If a user was found, it should bereturned with an id value even if it was not created via SCIM

The general logic of "Search using a friendly identifier -> create if not found/cache the id value and associated it with existing user in the other directory" is pretty simple and can be successfully used with other object types (ie: groups) as well.