Identity · SCIM Provisioning
Users and groups that stay in sync on their own
We add SCIM 2.0 provisioning to Keycloak through a vetted open-source extension or a custom SPI, and keep it working across every Keycloak upgrade. Your customers' directories create, update and deactivate accounts without a ticket in sight.
- SCIM 2.0 users & groups
- Joiner, mover & leaver automation
- Maintained across Keycloak upgrades
Standards & integrations
- SCIM 2.0
- RFC 7643
- RFC 7644
- Okta
- Microsoft Entra ID
- Google Workspace
- Keycloak SPI
Overview
Provisioning is what makes offboarding real
SSO decides how people sign in; provisioning decides whether their account should exist at all. With SCIM, a customer's directory creates the account when someone joins, updates it when they change teams, and deactivates it the day they leave. Keycloak needs an extension to speak SCIM, and every IdP's provisioning client has its own quirks — we handle both so the sync can be trusted.
What we deliver
- SCIM 2.0 extension selected, reviewed and packaged with your Keycloak build
- Attribute and group mapping specification per source IdP
- Provisioning setup guides for Okta and Entra ID admins
- Joiner, mover and leaver test suite
- Conflict and error-handling runbook
- Upgrade compatibility checks in your release pipeline
Capabilities
What SCIM Provisioning covers
Configured, tested and documented on upstream Keycloak — then handed over or operated by us.
A SCIM 2.0 endpoint for Keycloak
Users and Groups resources exposed per realm through a vetted open-source extension or a custom SPI, protected by scoped credentials for each provisioning client.
Inbound from your customers' IdPs
Okta and Microsoft Entra ID push creates, updates and group changes straight into Keycloak, so accounts exist before a user's first login.
Leavers handled on time
A deactivation in the source directory disables the Keycloak account and signs out its active sessions, rather than waiting for someone to notice.
Group and role mapping
Directory groups arrive as Keycloak groups carrying your role mappings, so a team change in the IdP changes access in your applications.
Conflict handling
Clear rules for duplicate usernames, pre-existing local accounts and attribute clashes, with failures logged for review instead of silently skipped.
Outbound when you need it
Where downstream systems need accounts pushed to them, Keycloak events drive outbound SCIM calls through an event listener, keeping those systems aligned as well.
How it works
From first call to production
Choose the provisioning design
We confirm which directories are authoritative, which attributes and groups flow, and whether an existing open-source extension fits or a custom SPI is the better long-term choice.
Test against each IdP's client
The SCIM endpoint is deployed to staging and exercised by each IdP's own provisioning client, covering create, update, group moves, deactivation and reactivation.
Keep it working through upgrades
Provisioning joins our upgrade test suite, so a new Keycloak release is only promoted once the extension has been rebuilt and verified against it.
Use cases
Where teams put it to work
Enterprise customer onboarding
B2B customers connect their Okta or Entra ID tenant once, and their users and groups appear in your product without CSV uploads or manual invites.
Automated offboarding
Leavers lose access when IT deactivates them in the directory, closing the gap between someone leaving and their accounts being disabled.
Access ready on day one
New joiners have accounts, groups and roles in place before they start, so their first login lands them in the right workspace.
FAQ
SCIM Provisioning questions, answered
Isn't SCIM built into Keycloak?
Upstream Keycloak doesn't provide a supported SCIM 2.0 server endpoint today, so we add one as an extension that runs inside your Keycloak. If native support arrives in a future release, we plan the move to it as part of a regular upgrade.
Should we use an open-source extension or a custom SPI?
It depends on your IdPs, your attribute model and how much you want to own. We review candidate extensions for code quality, licence, maintenance activity and test coverage; if none fit, we build a focused SPI and maintain it with you.
Does this work with Google Workspace?
Google Workspace's automatic provisioning targets apps from its own catalogue rather than arbitrary SCIM endpoints. For Google-sourced users we typically sync through the Google Directory API, or create accounts just in time at first login.
What happens when a user is removed in the IdP?
Okta and Entra ID usually deactivate rather than delete. We map that to disabling the Keycloak account and ending its sessions, and agree a retention period with you before anything is hard-deleted.
Ready to roll out SCIM Provisioning?
Walk us through your requirements on a free strategy call. We'll come back with an architecture, a delivery plan and a fixed scope.