Wild that they don't mention in the article that they offer SCIM, apparently at no extra cost? Most auth providers do not offer that, typically they will charge you per end customer/tenant. For example WorkOS charges $125/month for SCIM (on top of 125/month for SSO).
Stytch is also $125/month, and frontegg is similar.
Something I wish SCIM did better was break apart group memberships from the user resource. In the realm of SCIM's schema with the ability to have write-only, read/write, and read-only properties it makes a ton of sense to have a user's group memberships read-only and available to look at easily. But sometimes populating the list of groups a member is in can be taxing depending on your user/group db (or SaaS) solution. Especially because this data is not paginated.
SCIM allows clients to ignore the group membership lists via `?excludeAttributes=groups` (or members on the group resource). But not all clients send that by default. Entra does well to only ask for a list of groups or members on resources when it's really needed in my experience.
Some enterprise customers use SCIM with tons of users. Querying for the users themselves is simple because querying users is paginated and you can constrain the results. But returning a single group with 10,000 users in a single response can be a lot. It only really contains the user's identifier and optionally their display name, but if you have to pull this data from a paginated API it'll take a while to respond. Or it could still be taxing on some databases.
It'd be nice to query `/Users/:id/groups` or `/Groups/:id/members in a paginated fashion similar to `/Users`.
Pure chance - what should get assigned to me mere hours after reading this article but a ticket regarding SCIM users not being disabled with Entra...
> It turns out that Microsoft’s default behavior sends a boolean value as a string
> You can force Microsoft to send you the proper JSON if you use a certain feature flag (aadOptscim062020), but that’s really not an obvious solution!
Boom. That was exactly my issue.
> This sort of stuff is very time-consuming and demoralizing to resolve.
I would have sunk hours into this - thanks Ned O'Leary - you made my day!
Another point: the SCIM schema can be confusing. The RFCs make it seem like you can define your schema however you like, and it provides a default schema with which it bases examples in other parts of the RFC.
In reality, most systems expect you to have the full default schema present without modifications and might complain when items are missing. Do you provide scim support without passwords (only SSO)? Okta will send a password anyway (random and unused). Does your application not differentiate between username and email? IdPs will complain if they can't set them separately. Do you not store the user's `costCenter`? IdPs will get mad and keep trying to set it because it never sticks.
Some of the time, you'll have to store SCIM attributes on your user objects which have no effect on your system at all.
The other side is making custom schema items. SCIM has you present these in the `/Schema` endpoints. But, no system (that I know of) actually looks at your schema to autopopulate items for mapping. Entra and Okta are great at letting your provide mapping from an IdP user to a SCIM user, and then you map SCIM users back to your app's users. But you typically have to follow app documentation to map things properly if it's not using the default schema entirely.
I like the way IR remotes work for your aircon. Sending the full state every key press. Think it many times is a lot better then supporting PATCH.
Something I found odd / unnecessary whilst building a SCIM client was that fields are supposed to be case-insensitive:
> Attribute names are case insensitive and > are often "camel-cased" (e.g., "camelCase")
Whilst it's not a huge deal to support this, to me this feels like complexity/flexibility for the sake of it - I'd prefer more rigidity and one correct way.
One thing I haven't completed for my SCIM client implementation is a decent grammar for parsing the filter parameters. Does anyone know of a comprehensive one, preferably peggy/pegjs?
One of the issues we had with implementing a SCIM handler was that our client's didn't use the bulk processing. This meant that when they added <insert large number> of people to our system, we'd be hit with a large amount of individual POSTs, and they literally all came together.
In hindsight we could've done many things differently, but the usage of this service is generally very spiky, so hard to scale, but wasteful to have additional servers just idling.
I have a question: (which I admit I could probably research myself)
It sounds like is is a sort of 'change-events' pub-subscribe approach, where dependent systems keep their state updated by doing deltas against what they currently store (if I misunderstood this part, the rest here probably is moot).
If that is true, is there anything in the system that guards against if a subscriber fails to ingest an event, for whatever technical reason (bug or systems/execution failure, e.g. network or overload), ie some sort of 'transaction' approach where a subscriber will keep receiving/being due an event, until he has reported back an "ACK I have processed that" ().
I am asking because otherwise it could lead to things like a user account staying open/active, even though an event said it should be deleted.
Some alternative mechanisms with other trade-offs could be things/events like "group X has changed, its current member list is now [...]". In that case, the mirrored group might eventually become consistent on a later update (as opposed to carrying an eternal memory left over by a missed update).
() I am vaguely aware true consistency guarantee is impossible in a distributed system, something about confused generals.
Anyone have experience self-hosting? Maybe with https://www.npmjs.com/package/scimgateway running standalone, or proxying to an existing user store? Curious if there be dragons— do you need a few hundred users before encountering them?
Isn’t this also what federation is for? And managing those „relationships“ on only one domain. I struggle to see what SCIM brings additionally?
Nice to see an article of this type not titled "What every developer needs to know about X"
Nothing mentioned about how you can charge extra like the SSO tax??
I don't get the `SCIM doesn’t really have anything to do with data retention.`; if SCIM store data to sync between diff. integration / backend / ERPs / tools it is possibly impacted by data protection law like GDPR and co.
[flagged]
When I first looked into SCIM, the RFCs and endless tutorials were pretty dry. I wanted a playground to try things out, see what’s possible, and test my integrations. So I built one: https://scim.dev
(You’ll also see that the author is right: “The SCIM specification is basically good, but has some subtle details”)