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.
In practice, identity providers (Okta, Entra, etc.) will retry for a bit before reporting to the IDP admin that their SCIM connection to the SaaS vendor is unhealthy. From there, things get fixed ad-hoc.
Okta and Entra have different request patterns, and so have differing artifacts if the SaaS vendor's state diverges from the desired state. Okta tends to be more stable, because they usually GET-then-PUT (c.f. compare-and-set). Entra likes to PATCH, which leads to dead-reckoning artifacts.
What you're describing is an interesting and hard problem in computer science, but SCIM is not trying that hard to get it right.
My understanding of it is that it's just a bunch of well known HTTP endpoints that a server will call as things happen (eg: user is disabled).
I think the general intention is that these can/should be retried until the caller receives a successful response indicating the other system has updated its records.
(I'm not an expert in SCIM but I've played around with it, so could be wrong)
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.