Provision users and groups
An owner with an interactive session creates or rotates the organization token throughPOST /api/organizations/identity/scim/token, with an expiresAt ISO timestamp
within 366 days. The plaintext token is returned once; only its SHA-256 is stored.
Rotation invalidates the previous token immediately. API keys, saved CLI sessions
and OAuth automation credentials cannot perform owner identity mutations.
Configure the IdP provisioning base URL as https://your-app/scim/v2 and use the
token as a bearer credential. Canonical /api/auth/scim/v2 resource self-links
also accept the standard methods. Requests, including chunked bodies, are limited
to one MiB before parsing.
Create directory groups, then map their returned SCIM IDs using
PUT /api/organizations/identity/scim/group-role-mappings with groupId and
role (viewer, member or admin). Unmapped groups grant no membership;
owner is never a mapped role. Mapping changes reconcile current members
transactionally; deleting a group removes its mapping and grants. Owner and
break-glass accounts stay outside SCIM and cannot be altered by provisioning:
a SCIM request that changes an owner is refused and rolled back, so the IdP
reports the error. When a mapping change reconciles a whole group, an owner in
it is skipped and audited (identity.scim.owner_skipped) and everyone else is
still projected.
Until the first group is mapped, provisioning does not change memberships:
linked members keep their current role and the skip is audited
(identity.scim.projection_deferred). Provisioned users are still recorded as
directory-managed, so SSO just-in-time membership cannot grant them access
outside your mappings. Mapping the first group makes SCIM authoritative for
every linked user at once: users in no mapped group lose access then. Map
groups before relying on SCIM for access; deactivation applies immediately
either way.
Deactivation and deletion remove access and revoke this organization’s API,
CLI and OAuth credentials and provider-bound sessions. Durable lifecycle records
prevent SSO/JIT from restoring deactivated access. Other organizations retain
their memberships and sessions; global user profiles and authored data remain.
Preserve a stable externalId in the IdP. Re-creating a deleted resource without
one can conflict with the preserved global identity; do not work around this by
linking arbitrary global emails. Existing verified members can link only within
the same organization and its verified domain, without overwriting their profile.
Enable SAML logout deliberately
SLO defaults off. A reviewed SAML provider can opt in through its existing PATCH operation usingsingleLogoutEnabled: true; its IdP metadata must advertise a
logout endpoint. Requests must be signed, timely, bound to the provider and
protected against replay. Logout revokes sessions created by that provider in
that organization, preserving unrelated browser sessions and cookies.
This does not assert that an IdP ends sessions in every other application. Test
IdP-initiated, SP-initiated, unsigned, replayed and unrelated-session cases against
your actual test tenant before making a live logout claim.
Collect live acceptance evidence
scripts/identity-live-acceptance.ts --config probes.json --dry-run validates
configured coverage of all six documented acceptance phases without a network
request. A live run requires an operator’s configured test tenant, approved
requests and authorization. Reports retain status, response digests and audit IDs,
not response bodies or credentials. They always leave productionVerified false;
HTTP probe success alone is not complete browser/IdP acceptance.
The six phases cover provider/domain setup, sign-in/linking, enforcement and
revocation, invalid/replayed assertions, MFA recovery/rollback, and retained audit
evidence. Actual dated Okta and Entra acceptance remains [TO CONFIRM].