In this portion of the Okta documentation for SCIM v2.0, there are two examples of requests and responses for creating a user. The second example shows a scenario where the SCIM server has custom attributes that it wants to apply for each user entity. It demonstrates how the custom attribute is included in the reponse to Okta, which makes sense. What doesn’t make sense is why the externalID is left out of the request and is instead also included in the response to Okta. The documentation even points this out specifically:
In this example, the externalID and userType attributes weren’t included in the original POST method request, but are generated and returned in the SCIM server response.
Why would custom attributes mean that the externalID should not be included in the request and why would the SCIM server be responsible for creating an externalID? I would have thought that all Okta users already have an externalID to begin with and can be used in every request.
externalID is the identifier, which exists on SCIM side and allows that system to find a user by this ID. So Okta doesn’t have any externalID until it creates a user through SCIM (or gets it by search operation), when this ID would be returned back by SCIM server, so that next time Okta can send it to SCIM to modify the user (or deactivate)
Thank you for your response, but sorry to say that I’m still seeing things that would conflict with what you said. In the first example of request and response for creating a user in the same documentation that I linked in my original post, you can see that the request already contains the externalID and that the response contains both an id and an externalID. I’m fairly certain that the id is what you’re referring to in your answer and that the externalID is supposed to come from and exist in Okta already. Otherwise, how would they be able to supply it in the request before the user is ever created on the SCIM side?
Snowflake’s documentation on SCIM corroborates this as you can see in the user attribute table that they have the id described as their unique identifier and they have the externalID described as “The unique identifier set by the provisioning client (e.g., Azure, Okta).”
Okta’s own Joel Franusic also has a video on SCIM where at the 7:35 mark he talks about how the externalID is how the system that sent the user over to the SCIM API identifies the user, and that its helpful to store it in addition to the id as well.
So, I think my question still stands unfortunately for both of us. It doesn’t make sense why the externalID would be included in the first example, but omitted in the second and described as generated for the response.
Well, have to admit that you may be right. I was thinking more about OPP provisioning mechanism. I don’t have a SCIM server nearby to check myself, but what do you see in the CREATE request, when Okta pushes a new user to your SCIM server? Does it have externalID in it? I think that would be an ultimate test, which will answer all your questions
That’s a great question. We are early in the preliminary stages of accommodating SCIM for existing SSO clients. Once we get things set up to start experimenting with requests, we will certainly be looking into how the attributes work and will hopefully figure out which will be the best option for uniquely identifying user entities across both the client and the SCIM server. For now, it seems that userName is the only viable attribute to start since it is the only one available to both sides and uniquely restricted.
I do still think that the portion of the documentation I pointed out is hard to understand though. The concept of an externalID seems to possibly have two different meanings depending on who you talk to.
I agree with your observation. I also had a misunderstanding of its purpose. This article (https://ldapwiki.com/wiki/SCIM%20externalId) gives a bit of a context for the attribute and its purpose.
Good luck with the implementation, and maybe somebody else can share their experience
Well, I got too curious to go and check myself quickly, and I confirm, that I see externalID sent to SCIM during create user event (POST /Users), so I guess, it’ll be there all the time, as it’s stated in the link I provided in my earlier response.
Though it’s bit useless, I guess, but just a notice, that it’s equal to user GUID in Okta
I can’t thank you enough for linking this super useful documentation and for also going to the trouble of checking on the actual behavior. I really appreciate it.
Those docs do seem to indicate that the externalID could prove useful as an alternative to username for performing existence checks, which is what initially made me curious about it and led me to try and understand exactly what it is and what it could be used for. But I’m still thinking that in the case where one would enable SCIM provisioning for an app integration that has already existed in the SSO client with active users that have already been assigned to it, there would be the issue of having users on the SCIM server side that have no knowledge of their externalID.
I wonder if it would be a viable approach to do some kind of initial import/export effort that keys off of username and then once both sides are effectively synced and all SCIM server users have their externalIDs persisted, then you can switch the user provisioning configuration in Okta to start keying off of externalID for the existence filter checks instead. Any thoughts on that or on the usage of the externalID in general?
A word of caution for the scenario, where you want to enable provisioning for the app with existing users. Okta won’t push them into your SCIM after you enabled provisioning. I think recently there was a new functionality enabled to push those ones manually, otherwise only new users would be pushed out, when they get assigned to the app.
For existing user base you can also implement import operation from SCIM, to tie existing users to Okta users, so that Okta updates are propagated back to the linked users.
In all other scenarios (based on my OPP provisioning experience) I’d say you can safely work with userName which is sent to SCIM as a part of provisioning calls, to act as a substitution for externalId, assuming userName is unique
I appreciate the heads up! Yeah, userName is seeming more and more like the conventional/accepted way to go for the existence check query. At least I can’t find evidence of anyone using externalID in the eq filters instead. The main point of contention we had is that it causes some unfortunate restrictions on e-mail usage because of how most Okta userNames are required to be e-mail formatted. The email format name is then mapped to the e-mail field on our end as well. May just need to revisit how the attributes are mapped over.
