When a user is deprovisioned through SCIM, act on the SCIM resource within the tenant authorized for that provisioning client—not automatically on a shared person or account across the whole SaaS product. A tenant’s offboarding event should revoke that tenant’s access and remove or disable its membership; delete a global identity only if the product’s identity model and its other memberships allow it. Permanent erasure of business data is a separate retention decision.
What does SCIM deprovisioning actually remove?
SCIM deprovisioning is an operation on a SCIM resource. In a multi-tenant service, the application must decide how that resource maps to its own data. It might represent a tenant membership or a tenant-scoped account, rather than a person’s single, shared identity. RFC 7644 leaves the multi-tenancy scheme to the service provider; it does not prescribe a universal mapping between a SCIM user and an application’s identity records. RFC 7644
Keep these outcomes distinct:
- Revoke access: prevent sign-in or API access, often by setting the SCIM User resource’s
activeattribute tofalse. - Remove tenant membership: end the person’s association with the tenant whose identity provider sent the event, including its tenant-specific roles or group assignments as defined by the product.
- Delete a global identity: remove a shared person or account record. Do this only when the product’s identity model and remaining tenant memberships permit it.
- Erase retained data: purge application records, audit history, exports, or backups under a separate policy that accounts for the product’s commitments and applicable legal obligations.
These are related but not interchangeable. In particular, an instruction from one tenant should not silently remove another tenant’s access.
What does SCIM DELETE require?
Under RFC 7644 §3.6, a client requests removal of a resource with HTTP DELETE. The service provider may retain the resource internally instead of permanently erasing it. However, the protocol requires a previously deleted resource to return 404 for subsequent operations and to be omitted from future query results. In other words, SCIM defines observable behavior through the API; it does not dictate which underlying application records must be physically purged or set a retention schedule for related business data. RFC 7644
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallThat distinction matters when a product soft-deletes or retains records for audit, operational, or other policy reasons. Internal retention must still be consistent with the SCIM resource no longer being available through the protocol as required.
How should tenant boundaries and identifiers work?
RFC 7644 §6 does not define a universal way to register tenants, associate a SCIM client with a tenant, or identify the tenant in each request and response. The service provider must establish that association and secure any cross-tenant operations. Bind each provisioning client to the tenant or tenants it is allowed to manage, and use that authorized context for both lookup and mutation. RFC 7644
Identifiers must be interpreted within that boundary. The RFC allows provider-assigned SCIM id values not to be globally unique across tenants; client-assigned externalId needs to be unique only among resources associated with a tenant. Therefore, do not treat externalId as a global person key. Resolve it within the authenticated client’s authorized tenant context.
A risky design is to look up a global record by externalId and then delete it without checking tenant authorization or other memberships. Scope the resource resolution and resulting action to the tenant context before changing data.
Rank #3
How do disable and DELETE differ in practice?
There is no single vendor-independent application meaning for every deprovisioning action. For SCIM applications, Microsoft Entra describes a disable operation as a request to set active to false, while noting that disable and delete behavior varies by target application. Microsoft Entra provisioning behavior
GitHub Enterprise Cloud documents a product-specific distinction: soft deprovisioning sets active to false, suspends the user, and obfuscates login and email fields; hard deprovisioning sends DELETE and is described as irreversible suspension. That is GitHub’s documented behavior, not a universal definition of SCIM DELETE. GitHub Enterprise Cloud SCIM REST API
Microsoft’s Entra SCIM API reference documents DELETE /users/{id} returning HTTP 204 on success. This is one vendor API contract; it does not mean every application record associated with that person must be erased. Microsoft Entra SCIM API reference
When defining behavior for your own service, document the exact effect of each action: whether active:false disables a membership, suspends an account, or triggers another transition; what DELETE removes from the SCIM resource model; and whether internal retention follows. Use precise product behavior rather than relying on labels such as “soft” or “hard.”
Recommended Free Tools
Quick Recap
Best Value
How should a multi-tenant SaaS implement deprovisioning?
- Model identity separately from membership. Keep the person or login identity distinct from each tenant relationship. Store tenant-specific roles, group assignments, provisioning identifiers, and access state with the membership where appropriate.
- Authorize before resolving or mutating. Bind each SCIM client to its permitted tenant context. Scope resource lookups and changes to that context rather than finding a global record by
externalIdand applying an unscoped delete. - Apply the requested action at the correct scope. For an offboarding event from one tenant, disable or remove that tenant’s membership according to the documented mapping. Check remaining memberships before deleting a shared global identity.
- Keep data erasure separate. Define purge and retention behavior for business records, audit logs, exports, and backups outside the SCIM resource operation. The protocol does not establish a universal retention period; product policy, contracts, and applicable legal obligations govern those rules.
- Test tenant crossover and retries. In a sandbox, confirm that a client cannot mutate another tenant’s resource, repeated deprovisioning has a defined result, and disabling or deleting one membership leaves unrelated tenant access intact.
What should administrators and implementers verify?
- Which application resource does the SCIM User represent: a tenant membership, a tenant-scoped account, or something else?
- What does the IdP’s disable action send, and what does the SaaS do with
active:false? - What exactly does DELETE remove from the SCIM resource view, and what response and later query behavior does the API provide?
- Can the provisioning client resolve or modify records only in its authorized tenant context?
- Will the offboarding action preserve other tenant memberships and access?
- Which separate policy governs retention or erasure of business data, audit history, exports, and backups?
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
