SCIM architecture

A SCIM deployment has three moving parts: the identity provider's provisioning client, the application's SCIM service provider, and the application's own identity store behind it. The client pushes users and groups over HTTPS with a bearer credential; the service provider exposes the resource endpoints (/Users, /Groups), the discovery trio (/ServiceProviderConfig, /ResourceTypes, /Schemas), and applies each request to the store (RFC 7644 Sections 3.2 and 4, retrieved 2026-11-01). The store itself never speaks SCIM; the service provider is the translation layer.

Almost no application's core store was designed around SCIM. RFC 9865's motivation section states the common shape directly: SCIM service providers are usually wrappers over backends that already paginate with their own mechanisms, and translating between those and the protocol forces full iteration and result materialization (RFC 9865 Section 1, retrieved 2026-11-01). The same wrapper pattern explains most implementation quirks: cursor storage under an offset-paging protocol (AWS documents cursor pagination and lists startIndex as not supported despite the protocol's language; AWS developer guide, accessed 2026-11-01), attributes that exist in SCIM but have no backing field, and group membership that only resolves one direction.

The facade role also defines the discovery contract. Clients SHOULD learn endpoints from /ResourceTypes rather than assume pluralizations, and capabilities from /ServiceProviderConfig (RFC 7644 Section 4, RFC 7643 Section 6). A service provider that advertises a capability it does not implement, or implements one it does not advertise, converts discovery from a contract into a liability; the filter playground on this site models the provider-subset problem from the client's side.

RFC 7643 Section 3.1 makes meta server-assigned and read-only: created,lastModified, location, and version are the service provider's bookkeeping, and RFC 7644 Section 3.14 has a supported ETag specified as an HTTP header (MUST) and withinmeta.version (SHOULD). The rule that carries the sync quality of the whole deployment: bump meta.lastModified on every write, including the writes that arrive through paths other than the SCIM endpoint.

Downstream clients build their delta logic on that field. Okta's incremental import imports the full user profile when any attribute has changed since the last successful import, and its SCIM documentation listsmeta.lastModified among the metadata that import mechanics rely on (Okta provisioning agent and SCIM docs, accessed 2026-11-01). SailPoint's connectors run delta aggregation the same way, fetching changes since the last aggregation, and the quality of that delta is bounded by the server's change bookkeeping (SailPoint connector documentation and community guidance, accessed 2026-11-01). A service provider that leaves lastModified stale after a write does not fail any request; it silently degrades every downstream delta import into a full import or, worse, into missed changes.

Nothing in the conformance landscape catches this. The Entra SCIM Validator's ten documented validations exercise create, read-by-filter, PATCH, and the active toggle (validator tutorial, updated 2026-08-29); requirement-mapped suites test what the RFCs state as RFC 2119 requirements, and none of the surveyed tools asserts lastModified freshness after a write (tooling survey behind this lab-site, 2026-11-01). The rule is testable in one line: write, then read, then compare. Deployments that skip it find the degradation in the identity provider's import logs months later.

"On-premises SCIM" sounds like an inbound exposure; it is the opposite. The Entra Connect Provisioning Agent is a Windows service installed inside the customer network that authenticates outbound to Entra at setup and then provides "connectivity to Microsoft Entra ID without opening any inbound ports" (Microsoft provisioning agent documentation, accessed 2026-11-01). The SCIM endpoint it serves sits inside the network; the direction of initiation is still cloud-push.

Two deployment consequences follow. The endpoint must be reachable from the agent, not from the internet, so the agent's egress path is part of the availability surface (a firewall or proxy between agent and endpoint now terminates provisioning). The same SCIM requirements apply unchanged at the agent's target: the TLS floor, the media type, and the response contracts are the client's rules enforced at the agent's target, not a milder "internal" profile. Okta's provisioning agent behaves the same way on the import side, pulling from the endpoint on Okta's schedule (Okta provisioning documentation, accessed 2026-11-01).