Enterprise provisioning
SCIM is a standard API through which a company’s identity provider sends changes to users and groups. This guide describes a proposed integration. Contact your installation administrator to confirm availability, supported operations and connection details before configuring a connector.
Sign-in and provisioning
Single sign-on lets a person authenticate through their company. Provisioning lets the company report a transfer or departure while that person already has an open browser session. LDAP-backed Keycloak deployments can import users and periodically synchronize changed records. A Google sign-in link alone supplies no continuous membership feed.
Connecting a provisioning service
The planned Primero SCIM endpoint accepts a provisioning credential bound to exactly one tenant and directory connection. Your installation administrator supplies the endpoint and credential setup after the connector is available and qualified. Store the credential in your provisioning system and rotate it independently of sign-in credentials. This connection boundary applies to both shared and dedicated realm installations.
Primero resolves every user and group through that connection's directory records. The service restricts reads and profile changes to approved fields and translates supported operations into controlled Keycloak administration actions. Identity links and permission mappings remain under platform control. New accounts stay pending until their immutable identity linkage and admission requirements are verified.
Supported operations and availability
This is a planned integration. Enable customer provisioning after the installation has verified credential isolation, identity linkage, supported request patterns, update ordering and offboarding with an active browser session. Obtain the supported attributes, filters and PATCH behavior from the endpoint's SCIM discovery responses. Unsupported changes are rejected.
The intended contract covers scoped user creation, reads and approved profile updates, account deactivation, and source-managed group membership changes. Requests carry source versions or equivalent ordering and idempotency controls. A complete directory snapshot must be explicitly identified so a partial response cannot be treated as a complete member list.
Deactivation and restoration
When a connector requests deactivation through active=false or deletion, Primero first commits a tenant access hold. It then removes the affected admission and authorization memberships, suspends the tenant principal, and revokes the associated sessions and delegation. A shared account is disabled only when it has no other active membership or principal. Deletion records a tombstone and follows the retention workflow.
Removing a group withdraws that source's membership and derived access. Restoration requires current identity linkage and admission checks, including any manual suspension. Replayed or older updates cannot restore a removed account or clear a security hold. Measure offboarding from the administrator's action through the first denied protected request.
Large directories
For large cohorts, the proposed design uses incremental changes for each customer and a periodic full comparison to catch missed updates. A routine refresh would continue serving the previous verified result within its freshness limit. Confirmed denials must take effect immediately and survive older snapshots. Agree on the tolerated offboarding delay and measure from the administrator’s action through the first denied request.