On this page
What SCIM 2.0 provisioning is
SCIM is the System for Cross-domain Identity Management, an open standard for moving user records between systems. SenseCrypt exposes a SCIM 2.0 endpoint and acts as the service provider. Your directory acts as the client and pushes changes to it.
The premise of the standard is that your directory is already the truth. Provisioning is how that truth reaches the identity provider without anyone retyping it.
SenseCrypt is the SCIM service provider
Your identity source drives every change. SenseCrypt does not poll your directory and does not hold a second copy of your joiner and leaver process.
Your directory keeps deciding who exists
Accounts appear and are deactivated because your HR system or directory said so. That is the only arrangement in which access stays correct as people join, move, and leave.
How SCIM provisioning works
Your identity source calls the SenseCrypt SCIM endpoint whenever a user record changes. A joiner creates a user. An attribute change updates one. A leaver is deactivated and can no longer sign in.
These are the plain SCIM 2.0 operations. Any connector that already speaks the standard, including the ones built into the large directories, works without custom code.
- POST to create a user
- PATCH or PUT to update attributes
- A single call to deactivate a user
- Filtered queries to reconcile what exists on both sides
What automatic provisioning is worth
The saving that gets quoted is the time spent creating accounts. The one that matters is on the way out. Manual deprovisioning is where orphaned accounts come from, and an orphaned account is an access path nobody is watching.
With SCIM the leaver process runs at the speed of your directory instead of the speed of a ticket queue.
Leavers lose access when your directory says so
Deactivation propagates from your identity source. Nobody has to remember a second system during an offboarding.
Joiners arrive ready
The account and its group memberships exist before the first day, so the only step left for the user is enrollment.
Provisioning events are recorded
Each provisioning call is written to the tenant's audit log, so you can show when an account was created, changed, or deactivated.
How SCIM fits your stack
SCIM answers who exists. It never signs anyone in. That is the job of OIDC or SAML, and keeping the two ideas apart makes the work far easier to scope.
In a normal deployment they run together. Your directory provisions the account over SCIM, and the user then signs in by face through OIDC or SAML.
Pair SCIM with OIDC or SAML
Provisioning and single sign-on are separate standards solving separate problems. You want both, and SenseCrypt speaks both.
Group membership feeds the roles
The groups your directory provisions feed the roles and permissions SenseCrypt resolves at sign-in and emits in the token, which your application then enforces.
Start on the 30-day trial
No card is needed. Point your directory's SCIM connector at the endpoint and watch a real joiner and a real leaver run end to end.
Frequently asked questions
Does SenseCrypt support SCIM 2.0?
Yes. SenseCrypt exposes a SCIM 2.0 endpoint. Your identity source provisions and deactivates users through it.
What can SCIM provisioning do?
It creates, updates, and deactivates user accounts. Your directory drives each change. Access stays in sync with your identity source.
Does SCIM replace single sign-on?
No. SCIM provisions the accounts. OIDC or SAML single sign-on (SSO) signs the user in. SenseCrypt supports both.
Related