Treat provisioning as a lifecycle contract
SCIM can standardize how identity information is exchanged, but saying a platform supports SCIM does not establish its complete access lifecycle. The requirements must identify which resources and attributes are supported, how users are bound to tenants, what role changes mean and how disablement affects existing access. A provisioning response is not automatically evidence that every session, export permission or API credential has been revoked.
RFC 7643 defines the SCIM core schema, including User and Group resources. RFC 7644 defines the protocol operations and considerations for provisioning. These primary specifications provide a vocabulary for requirements, not proof that EmailAuth implements any particular endpoint or lifecycle behavior. No user was created, changed, disabled or deleted in preparing this manuscript.
Establish identifiers and tenant binding
Record the service provider's resource identifier, the provisioning client's correlation identifier where used, and the tenant to which the operation applies. RFC 7643 distinguishes id from externalId; they should not be casually replaced by a mutable email address. A user's address or display name can change without implying that a new person should inherit an old account. Define how the application identifies an existing resource and prevents an update from targeting another tenant's user.
RFC 7644 discusses multi-tenancy and association of clients with tenants without prescribing one universal tenancy implementation. Require the actual supplier to explain its binding model: which authenticated provisioning client may operate on which tenant and resource set. A tenant identifier supplied in a request is not sufficient authorization by itself. The implementation must establish the relationship between the authenticated client and the requested scope, including list, search and lifecycle operations.
Specify supported resources and update behavior
Ask which User and Group attributes are accepted, returned, immutable, required or ignored. Document extensions and any mapping from group membership to application permissions. A successful update to a group object does not, by itself, prove that a corresponding application role changed. The access behavior must be confirmed separately. Avoid assuming that every SCIM-capable platform supports the same filters, PATCH operations or discovery endpoints.
RFC 7644 defines operations such as retrieval, creation, replacement, modification and deletion, and describes service-provider configuration discovery. Use those mechanisms to ask precise questions about supported capabilities. Preserve documented error behavior and concurrency support where applicable. If an operation is unsupported, record the supported alternative rather than treating a generic SCIM label as permission to use it. No endpoint discovery or request execution occurred in this work.
Define disablement without inventing revocation
RFC 7643 describes the User active attribute as an administrative-status indicator whose definitive meaning is determined by the service provider. This is a critical qualification. Setting active to false cannot be assumed to invalidate every active session, API token or delegated integration across all implementations. The requirement should state the intended access outcome and demand current platform evidence showing what actually changes.
Distinguish disabled users from deleted resources and from removal of a group membership. Each can have different consequences for access, retained audit records and later reactivation. Require the supplier to explain how existing sessions behave, how urgent revocation is performed and which noninteractive credentials are outside SCIM's lifecycle. If the platform requires a separate containment action, document that action and its authorization rather than hiding it behind an “offboarding complete” status.
Verify role changes and retained access
A role reduction is a particularly useful test because it can expose cached or incomplete authorization updates. Define an initial permitted action, apply the authorized lifecycle change in a fixture environment, and check that the now-disallowed action is denied according to the platform's documented timing. Keep the test description separate from a claim that it has run. Do not evaluate only whether a user-interface label changed.
Azure's multitenant identity guidance separates identity, authorization and entitlements. Apply that separation to the requirements: SCIM may carry user or group data while the application makes resource authorization and commercial-entitlement decisions. A removed license, disabled account and removed administrative role are not necessarily the same operation. Record which system owns each decision and how inconsistent states are detected.
An access-matrix worksheet
Create a matrix with provisioning client, bound tenant, target resource, operation, intended role or lifecycle state, expected authorization result and evidence location. Include read, search, export-related application access, write and user-lifecycle cases. Use at least two isolated tenant fixtures with distinguishable synthetic data so cross-tenant leakage cannot hide behind identical results. No real tenant data is needed for the proposed design.
Add negative cases for a client attempting to address another tenant's user, a search returning another tenant's records, a role reduction leaving administrative writes available, and a disabled identity retaining unsupported access. These are defensive acceptance cases, not instructions to probe a live service without authorization. Record the supported API and application behavior separately, because a SCIM update response and an application authorization decision are different evidence items.
Fictional diagnosis: a disabled record with an active session
A fictional evaluator sees a successful response after a test User resource is marked inactive. The evaluator initially marks offboarding complete. A requirements reviewer asks whether the application session that existed before the update can still read reports or initiate an export. The team realizes that the demonstration proved only that a provisioning operation was accepted, not the complete access outcome.
The proposed next step is to consult the supplier's current session behavior and run approved fixture-based checks. If separate revocation is required, the lifecycle procedure must include an authorized owner and verification. This scenario is fictional: no inactive user, active session or failed revocation was observed. It illustrates a missing acceptance criterion rather than asserting a defect in any real platform.
Plan reconciliation and exception handling
Define how provisioning failures are surfaced, retried and reconciled without duplicating users or broadening access. Record whether the client uses supported concurrency controls and how conflicting changes are handled. A temporary synchronization failure should not silently turn into a permanent permission exception. Equally, retries should not be described as safe without understanding the operation and the provider's behavior.
The catalogue requires an access matrix and negative tests covering cross-tenant reads, exports, writes and user lifecycle changes. Those original tests remain open. This manuscript supplies a proposed matrix and requirements, not implementation evidence. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. A publishable capability statement requires current supported behavior and authorized results from the actual platform, with no real user secrets or tenant data exposed.