SCIM
SCIM — System for Cross-domain Identity Management — is an open standard for creating, updating and deactivating user accounts in one system from another. In K-12 it is how staff accounts in an identity provider stay in step with accounts in each application.
| Endpoint or operation | What it does | Where implementations get thin |
|---|---|---|
POST /Users | Creates an account | Duplicate handling when a user already exists under another key |
GET /Users?filter= | Looks up by attribute | Most servers support only userName eq |
PATCH /Users/{id} | Changes named attributes | Partial PATCH support; some servers only honour PUT |
PUT /Users/{id} | Replaces the whole record | Blanks attributes the IdP did not send |
active=false | Soft-deletes — the account is disabled, the record survives | Applications that treat it as a hard delete and lose audit history |
/Groups | Role and group membership | Frequently unimplemented; roles then have to be managed by hand |
/ServiceProviderConfig | Declares what the server supports | Often missing, so the IdP has to guess |
totalResults | Drives IdP pagination | Returning the page size instead of the total breaks large syncs |
SCIM, rostering and SSO are three different jobs
These get conflated constantly, and the distinction is simple once stated:
- SCIM moves accounts. It runs on a schedule or on change, and it answers "who should have an account here, and is it still active?"
- Rostering moves enrolment. It answers "which students are in which schools and sections, and which adults belong to them?" See roster sync.
- SSO moves a login. It runs at the moment of sign-in and answers "is this the person they claim to be?"
They fail independently. SSO with no SCIM means a departed teacher cannot log in through the portal but their account and its data access still exist. SCIM with no SSO means accounts are accurate and everyone has a separate password to lose. Neither covers guardians, and that is the K-12 detail enterprise SCIM guides never mention: parents have no district-issued identity, no record in the IdP, and nothing to provision.
The real argument for SCIM is measured in hours
Every other benefit is convenience. The one that survives a security review is deprovisioning lag — the time between a staff member leaving and their access ending.
| Model | Typical lag | Why |
|---|---|---|
| Manual ticket per application | Days to never | Depends on somebody remembering every system |
| Quarterly access review | Up to a term | The review finds it; nothing raises it |
| Nightly HR or roster feed | Under 24 hours | The next run carries the change |
| SCIM on change | Minutes | The IdP pushes the deactivation as it happens |
For a communications platform this is not abstract. A departed staff member with a live account can still send to families — and a message from the district is trusted by definition. Whatever the provisioning model, the compensating control is an audit log that cannot be edited after the fact, so that a send is attributable no matter how the account was obtained.
What Kastr supports, and what it does not
Beta, with the limits named. Kastr implements SCIM 2.0 user provisioning in beta. Concretely: userName eq is the only supported filter; totalResults currently returns the page size rather than the true total, which will break pagination on identity providers that rely on it; there is no DELETE, no /Groups and no /ServiceProviderConfig. Deactivation via active=false works. SCIM requests are rate limited separately at 600 per minute per key.
If your identity team's plan is to provision staff into Kastr from Entra or Okta at district scale today, the pagination limitation is the one that will bite first, and you should scope around it rather than around a certification badge.
What does hold up is the surrounding surface. API keys are SHA-256 hashed at rest and the plaintext is shown exactly once. Every action is written to a per-organisation, tamper-evident audit log — a SHA-256 hash chain, append-only at two independent layers, with UPDATE and DELETE revoked at the database level and no policy that would permit either. So even where provisioning is manual, the record of who did what is defensible.
Questions people actually ask
Is SCIM the same as SSO?
No. SCIM creates, updates and deactivates accounts on a schedule or on change. SSO authenticates a person at the moment they sign in. Districts usually want both: SSO alone leaves orphaned accounts in place, and SCIM alone leaves everyone with separate passwords.
Does SCIM replace a roster sync for students?
No. SCIM provisions accounts, typically for staff. Rostering carries enrolment, sections and guardian relationships, which SCIM has no model for. Districts run both, and neither of them covers parents and guardians, who have no identity-provider record to provision from.
What happens to a user when SCIM sends active=false?
It should be a soft delete: the account is disabled immediately and the record and its history survive. An application that treats it as a hard delete destroys audit history along with the account, which is the wrong trade in any system that sends messages on a district's behalf.
Which identity providers support SCIM?
The major ones — Microsoft Entra ID, Okta, Google Workspace through partner connectors, and most other enterprise IdPs. The variable is not whether the IdP speaks SCIM but how completely the receiving application implements it, particularly filtering, pagination and group support.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers, no add-on modules, no per-message fees. Published on the site because you should not have to book a call to learn a price.