Provisioning

Cardinal is a SCIM server, not a client. An upstream identity provider (Entra, Okta, anything that speaks SCIM 2.0) pushes users and groups into it.

Base URL: <public-url>/scim/v2

/Users supports list, create, get, replace (PUT), patch and delete. /Groups supports list, create, get, patch and delete. There is no PUT on a group, so membership changes arrive as PATCH. /ServiceProviderConfig, /ResourceTypes and /Schemas are there for discovery, so a provider can configure itself.

Two things must both be true

cardinal service-account create entra-sync      # nobody signs in as a provisioner
cardinal grant provisioners entra-sync          # policy permits Provision
cardinal token create entra-sync -scope scim    # the credential says so too

The token must carry the scim scope and policy must permit its owner to Provision. Neither alone is enough.

That is not belt and braces. A token that could provision merely because its owner happens to be a provisioner would turn every other token that person holds into a provisioning credential, including the one on a laptop for reading the decision log.

A provider cannot make somebody an administrator

A system group is never provisionable. directory-admins and its siblings are refused, whatever the request says.

The reason is the shape of the trust relationship. Provisioning is an upstream system asserting who exists and what teams they are in. If that assertion could also place somebody in a group that confers authority inside Cardinal, then compromising the upstream provider, or an over-broad group mapping in its configuration, becomes administrative access here. Refusing it at the boundary means the worst an upstream mistake can do is create accounts and ordinary memberships.

In the console

There is no provisioning page. Accounts arriving over SCIM appear in Directory → People like anybody else, and the group memberships it creates appear on the groups.

The credential is issued with cardinal token create, which an administrator may do for a service account and not for a person: a token issued for somebody by somebody else acts as them. See access tokens.

Best for

• Estates where an HR system or an upstream IdP is already the source of truth for who exists, and Cardinal is the thing deciding what they may reach.
• Retiring accounts quickly. A deprovisioning push disables here, and disabling revokes sessions and tokens with it.

The trade-off

Two systems now believe they own the account list, and the failure mode is divergence rather than an error. A person created by hand in Cardinal is invisible to the upstream provider and will not be deprovisioned by it.

Decide which system is authoritative and be consistent. Cardinal does not enforce that choice for you.

Limits

• Inbound only. Cardinal does not push to anything over SCIM. Outbound notification is security events, which is a different protocol answering a different question.
• No /Me, no bulk operations, no filtering beyond the basics.
• No passkey provisioning, which is not a gap: credentials cannot be migrated, and a provisioned account still needs an invitation before anybody can sign in.
• No mapping configuration. Attributes land where they land; there is no UI for transforming them on the way in.