SCIM

SCIM is an open standard for provisioning user accounts and groups between systems. One directory is authoritative, and every change recorded there is pushed out to the applications that need to know.

Sign-on and provisioning are separate problems, and keeping them separate resolves most identity architecture arguments. SAML and OIDC answer whether this person may enter at this moment. SCIM answers whether an account exists in that system, which groups it sits in, and whether it should still be alive tomorrow.

The two are complementary rather than alternative. Federation without provisioning produces applications full of accounts nobody owns; provisioning without federation produces applications full of local passwords.

SCIM 2.0, specified in RFC 7644, is a REST API: JSON request bodies, conventional HTTP verbs, and a fixed schema covering users and groups. The identity provider acts as the client, pushing each change to the connected application, which applies it to its own directory.

The schema is what separates this from one more bespoke integration. Agreement on the shape of a user already exists, so nobody negotiates a field mapping for a user name or an active flag, and a provisioning client written once behaves predictably against the next target.

• /Users and /Groups: the standard resource endpoints every implementation exposes.
• POST creates a resource, PUT replaces it, and PATCH applies a partial update.
• DELETE removes an account, though many systems deactivate rather than destroy.
• Filter queries locate an existing resource, most often on userName or externalId.
• Core and enterprise schemas fix the attribute names, so neither side invents its own.
• A bearer token authenticates the provisioning client to the target system.

The security case for SCIM is offboarding, not onboarding. Creating an account late is an inconvenience that someone will complain about within the hour. Leaving one active after a person departs leaves a door standing open that no ticket tracks and nobody has reason to check.

Manual offboarding fails quietly and predictably. One application is missed, the checklist describes last year's tooling, the contractor was never on it at all, and the access survives for months. Automation matters here precisely because nothing about deprovisioning feels urgent to anybody who still works there.

SCIM is specified more tightly than most integration protocols and still leaves room for divergence in exactly the places that matter operationally. Two applications can both be compliant and behave differently on the path you care about most.

Exercise the leaver path against each connected application before trusting it, with a real account rather than a diagram. The exercise takes an afternoon and is the only way to learn what your particular estate does when somebody is removed.

SenseCrypt supports SCIM 2.0, which puts the account lifecycle and the authentication on one platform. A record provisioned from your authoritative directory is the same record that governs face enrollment, group membership and access, so there is no second directory to reconcile.

Provisioning creates what the platform calls a pending shell: a user record with a profile and group memberships but no face binding yet. A pending shell cannot sign in. The person binds their biometric on first use of the authenticator app, which is what keeps provisioning an administrative action and enrollment a personal one.

The provisioning client authenticates with an opaque bearer token minted in the console. It is tenant-scoped and displayed once, which is the secret token mode that provisioning systems generally expect.