SCIM 2.0 Provisioning
BetaInaya's SCIM 2.0 server: what it supports, how users and groups map to lifecycle events, and what is deliberately not supported.
Status: VERIFIED with Microsoft Entra (2026-09-26, on-demand provisioning); Okta UNVERIFIED. Implemented from RFC 7643/7644 and tested with SCIM requests. The real Entra provisioning service then passed its connection test, created a user (a joiner), and, after the user was disabled in Entra, sent the deactivation that ran a leaver with all six revocation steps verified. Not yet observed: a full scheduled provisioning cycle and Entra pushing group membership (on-demand runs create the group but do not carry members).
Entra setting you must change: Entra's default SCIM mapping sends
externalIdfrommailNickname, which can be renamed. Inaya treatsexternalIdas the immutable identity, so in the provisioning attribute mappings mapexternalIdfrom objectId before you start provisioning.
Set up
- Providers → connect a provider of kind scim (the external tenant id is any stable name for this connection).
- Credentials → create a credential with the scope
identity:scim, bound to that provider. It is shown once. - In your identity provider, set the SCIM base URL to
https://<your Inaya host>/api/scim/v2and the token to the credential.
What is supported
| Resource | Operations |
|---|---|
/Users | GET (list, filter=attr eq "value", startIndex, count ≤ 100), POST, GET /{id}, PUT, PATCH (replace active, userName, displayName, title, emails, enterprise department/employeeNumber), DELETE |
/Groups | GET, POST, GET /{id}, PUT (membership), PATCH (add/remove members), DELETE |
| Discovery | /ServiceProviderConfig, /ResourceTypes, /Schemas |
Filters: userName, externalId, emails.value, displayName, active, id with eq, joined by and.
Behavior you should know
- Every write is a lifecycle event. SCIM goes through the same engine as webhooks: tenant binding, immutable identity, ordering, mapping, approvals for privileged access, verified revocation, audit and evidence.
active: falseis a leaver.active: trueafterwards is a restore request handled by the provider's policy (default: a person must approve). A SCIM client cannot silently bring a revoked person back.DELETE /Users/{id}deactivates. Inaya never deletes a person's records because a directory said so. The record stays and showsactive: false.- Groups are virtual. A group is the set of users carrying that name. What a group means is decided by your group mappings in Inaya, never by SCIM, and a group cannot grant a privileged role on its own.
externalIdis the immutable identity and cannot be changed by PATCH. If a client omits it on create, the user name is used with ascim:prefix.- SCIM has no source timestamp, so events are ordered by arrival. A disable still wins over an enable at the same instant.
Not supported
Bulk operations, sorting, ETags, password changes, group renames, nested groups, co/sw/or/not filters. Each returns a SCIM error, never a silent partial result.
Related documentation
- Identity Integration (Active Directory, Entra, Rewst, SCIM)Let your directory, HR system, PSA or MSP automation drive who has access to Inaya. Joiners, movers and leavers change access automatically, a leaver is cut off at once, and Inaya stays the authority, verifying and recording every change.
- Microsoft Entra IDConnect your Entra tenant to Inaya: signed events, optional Microsoft Graph pull with your own app registration, and how this relates to Inaya's existing Microsoft sign-in.
- Joiner, Mover, LeaverWhat happens to Inaya access when someone joins, changes team or leaves; how immediate revocation works, its states, and the honest limits on tokens and sessions.
- Group and Attribute MappingHow directory groups and attributes become Inaya departments, projects and roles, why privileged access is never granted from an arbitrary group, and how manual overrides are kept.