Scenario: SCIM-enabled application integration (App A) exists in Okta. It is configured to use e-mail to check for the existence of a user in App A before sending them there for creation. User B is assigned to App A in Okta, so Okta wants to send User B to App A depending on the result of the existence check.
What will happen if User A, who already exists in App A, has that exact same e-mail? Will Okta be able to look at the payload for the GET response to the existence check and see that even though the e-mail matched, User A is indeed different because its GUID does not match any known GUID for User B? Or, how does that work? Is there a custom way to have the integration use GUIDs to do the existence check? But then it seems as though it wouldn’t have a GUID for brand new users who only exist in Okta.
I’m trying to figure out the significance of the fact that in the SCIM spec, it shows that the payload for the response to creating users contains a GUID. I’m also trying to figure out how to configure SCIM provisioning for my app since there seems to be multiple fields within the tabs of an Okta Application for specifying what a user ID should be.
In SCIM, okta is looking to match against something on the SP side that is known to be unique across all users. By default, this is the okta username, which is what we search for when checking to see if a user already exists in the SCIM server.
Note: The filter must check an attribute that is unique for all Users in the Service Provider profiles.
Since Okta wouldn’t know the GUID on your side until the user is matched (via the unique attribute) or created (where your SCIM server returns their ID back to Okta in its response), there’s no way this can be used the first time the user is assigned the application. Once the user is provisioned (or linked) in Okta, the GUID from your SCIM server will be stored in the user’s application profile as their External ID, and it will be used for any subsequent updates.
Have you read through our SCIM documentation, both the protocol reference above as well as this guide?
Thank you for the response and the nicely linked details, I appreciate that.
I have read through the documentation that you mentioned, but my concern is that given a scenario where the only truly unique attribute is the GUID itself, then it sounds like looking for matches via userName or e-mail will never be fully reliable, even though those sound like the only viable options since as you said, the SP’s GUID won’t be known until after creation.
Do you happen to know all the possible/expected attributes that the filter may use? Is it usually just Okta userName or e-mail? Which I guess may be the same since sometimes Okta userName is e-mail?