4 ms·

> SCIM 2.0 is built on a object model where a Resource is the common denominator and all SCIM objects are derived from it. It has id, externalId and meta as att

> SCIM 2.0 is built on a object model where a Resource is the common denominator and all SCIM objects are derived from it. It has id, externalId and meta as attribute and RFC7643 defines User, Group and EnterpriseUser that extends the common attributes. Hang on... zoom and enhance! > It has id, externalId and meta as attribute Uhhh, so a SCIM object can only only 1 `externalId` value? ...that's a deal-killer right there because Federated Identity schemes will need to handle users that have multiple external identity references (e.g. think how StackOverflow lets the same SO User login using Google, GitHub, even Facebook (in 2024?!) - how is that meant to be represented by SCIM? (I'll confess that I've only skimmed the SCIM docs; if I'm mistaken then I look forward to being told I'm wrong because it means I can learn something new today).

yellowapple 2y ago
"externalId" in this context is less "this is an ID that comes from an external identity reference" and more "this is an ID the creator of the record provided during the creation request" - in contrast with an internal ID, which is what the server uses internally to refer to the record (usually a sequential or random integer - in SCIM's case, a UUID). This is pretty common for enterprise software; you'll have the software itself generating an internal ID, but the user will provide an external ID to relate that record to its equivalents in other systems. Like with other enterprise software (that I've worked with), SCIM's externalId is optional - and you can see in the examples that it's usually duplicating some other field, like the username or an employee number. That optionality is a double-edged sword, though; if you're integrating software that expects an externalId to be set, then you gotta make sure it's indeed being set. Back when I was doing NetSuite administration/development full-time that bit me in the ass on many occasions; middleware would be opinionated about the externalId being set, and I'd have to make sure that was getting populated from whatever record-specific unique ID (e.g. tranId for transactions).
prng2021 2y ago
Logging into SO using a Google account is just authenticating a user using OAuth and is a different topic. A typical scenario for using SCIM is you get hired at a company and as part of onboarding, the company’s Okta tenant sends a SCIM request to automatically create an account for you in their corporate Stack Overflow tenant. As part of your SO profile creation, Okta can include an optional Okta-specific identifier which is how Okta distinguishes you from everyone else. This is the external ID. Why’s this field useful? Well it’s one way that Okta can quickly find your account in SO in the future to make profile updates like updating a job title profile field.
- TheNewsIsHere 2y ago
  Yeah, this is a typical way for IdPs and their protocols to work. If you’re federating with multiple disparate providers, you should be using something like Okta or Keycloak as a concentrator so the things that need to consume your directory service only have to consume one.

yellowapple 2y ago

"externalId" in this context is less "this is an ID that comes from an external identity reference" and more "this is an ID the creator of the record provided during the creation request" - in contrast with an internal ID, which is what the server uses internally to refer to the record (usually a sequential or random integer - in SCIM's case, a UUID). This is pretty common for enterprise software; you'll have the software itself generating an internal ID, but the user will provide an external ID to relate that record to its equivalents in other systems. Like with other enterprise software (that I've worked with), SCIM's externalId is optional - and you can see in the examples that it's usually duplicating some other field, like the username or an employee number. That optionality is a double-edged sword, though; if you're integrating software that expects an externalId to be set, then you gotta make sure it's indeed being set. Back when I was doing NetSuite administration/development full-time that bit me in the ass on many occasions; middleware would be opinionated about the externalId being set, and I'd have to make sure that was getting populated from whatever record-specific unique ID (e.g. tranId for transactions).

prng2021 2y ago

Logging into SO using a Google account is just authenticating a user using OAuth and is a different topic. A typical scenario for using SCIM is you get hired at a company and as part of onboarding, the company’s Okta tenant sends a SCIM request to automatically create an account for you in their corporate Stack Overflow tenant. As part of your SO profile creation, Okta can include an optional Okta-specific identifier which is how Okta distinguishes you from everyone else. This is the external ID. Why’s this field useful? Well it’s one way that Okta can quickly find your account in SO in the future to make profile updates like updating a job title profile field.

TheNewsIsHere 2y ago
Yeah, this is a typical way for IdPs and their protocols to work. If you’re federating with multiple disparate providers, you should be using something like Okta or Keycloak as a concentrator so the things that need to consume your directory service only have to consume one.