SCIM: System for Cross-Domain Identity Management | Hacker News Reader

SCIM: System for Cross-Domain Identity Management

scim.cloud

24 pointsstefankuehnel10 comments

SCIM is great, if your expectations are sufficiently low. Mostly for the fact that it’s a de-facto industry standard. Have a large stable of software products that your employees use? SCIM lets you provision and, importantly, de-provision users and assign them “groups” (roles) from your centralized Identity Management system. Most IdP’s and software will support SCIM, so it’s just wiring things up.

The biggest oversight when SCIM was designed was the expectation of an inbound connection from the provisioning software (e.g. Azure) to the SAAS or similar. This means that in hybrid environments (e.g. most large enterprises), you are having to whitelist umpteen different ip ranges from the Cloud Provider. Some IdP’s have solved this with a local agent you install on-premise to reverse the connection, but Azure is not one of these.

I thought IPs are trivial for hackers to spoof. Given that and the fact that providers like AWS publicly publish their IP ranges, I don’t understand why IP filtering is so common.

I don’t know, but I think it isn’t trivial to spoof public IP addresses owned by organisations. However, it’s trivial to host something in Azure/AWS, so this whitelist would have to somehow distinguish between “MS/Amazon things” and “MS/Amazon customer things”. Probably that’s possible, but the lists are large and the potential for human error is always there.

But this is beside the point. IP whitelisting is problematic for many reasons, and big enterprise sometimes simply refuses to do it. That’s not to say that SCIM is reliant on whitelisting for authentication, it isn’t. However, any modern design of this would have made the connection outbound from the thing being provisioned.

as i understand it, it is trivial to make it look like traffic came from an ip by spoofing the reply address. It is much harder to capture return traffic over the internet. (you have to either compromise every router between you and them, or announce new bgp routes)

in this case, as the value is in the reply data it’s not really feasible (unless you are a three letter agency)

Most people in the SAAS space know SCIM as the protocol that automatically enrolls new employees at customers into your product.

> 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).

"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).

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.

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.

SCIM is another acronym which means something else; in case of Unix desktops, an input method.

Reply on news.ycombinator.com