Keycloak user onboarding and offboarding: what workflows automate
Keycloak workflows can automate event-triggered and scheduled account steps, such as sending notifications and disabling users, but they are not a full joiner-mover-leaver governance product. This section is for IT and security leads who create, disable and review Keycloak accounts by hand and want fewer of those steps without giving up control over who holds access. Read it as a scoping guide: it sets out what the feature can carry inside Keycloak and where a separate identity governance tool needs to take over. Manual account work tends to grow with the user base, and it often falls to the same administrators who hold the most privileged access, which makes it a sensible place to start.
Teams usually look at workflows when the same administrative steps repeat across many accounts and timing matters. Typical examples are sending a welcome message after an account is created, notifying a manager before an account is disabled, and disabling accounts that have not signed in for a set period. As an illustrative case, a contractor whose engagement ends on a Friday should not keep working access until someone remembers to open the admin console on Monday. Workflows can close that gap, but only for events Keycloak itself can see. A leaver process that starts in an HR system still needs an integration, such as the SCIM provisioning covered elsewhere on this site, to bring that signal into Keycloak.
This page covers the two trigger patterns that workflows use: event-triggered steps that run when something happens in a realm, and scheduled steps that run on a timer. It also covers the notify and disable actions that build on them. It marks the boundary of the feature as well. Workflows do not provide joiner and mover approvals, role models mapped to job functions, reviewer campaigns, or evidence that a periodic access review took place. Those controls belong in an identity governance product or in a documented process around Keycloak. Knowing that boundary early keeps the design honest, because a workflow that disables accounts quietly is only as trustworthy as the rules that decide which accounts it touches.
The exact step types, their configuration options and their maturity depend on the Keycloak release you run. Confirm them in the server administration guide for your version before you commit to a design, and check the upgrade notes for changes that affect the same features. Before building, decide which events should trigger a step, who receives each notification, whether a disabled account is deleted later or kept for audit, and how break-glass administrator accounts are excluded from inactivity rules. Test each rule in a non-production realm with test accounts, and record the results, because those tests become the evidence you will show when someone asks how a leaver is handled.
Which lifecycle steps to automate and which to keep manual
This table compares common joiner, leaver and inactivity steps by trigger type, reversibility, and whether Keycloak can run each step alone or an upstream HR or governance system must drive it. Event-triggered steps react to a change, while scheduled steps run on a timer and can catch changes that events miss. Confirm in your Keycloak release which workflow triggers and actions are available before you assign any step to Keycloak alone.
| Lifecycle step | Trigger type | Reversibility | Keycloak alone or upstream system |
|---|---|---|---|
| Account creation | Event-triggered from an HR or provisioning feed, or manual entry in the admin console | Reversible: the account can be disabled or deleted | Usually driven upstream, since the HR record should be the source of identity |
| Group and role assignment | Event-triggered on account creation or job change, plus scheduled reconciliation | Reversible, but removing access can break work users still need | Keycloak can apply the assignments, but the mapping rules usually come from upstream |
| Welcome notification | Event-triggered after account creation | Not reversible once the message is sent | Keycloak alone, if your release supports this action; confirm email settings first |
| Disabling on termination | Event-triggered from a termination record with an effective date | Reversible if the account is disabled, not deleted | Upstream system decides; Keycloak executes the disable |
| Inactivity disablement | Scheduled, based on last login time from stored event data | Reversible by re-enabling, but needs testing for unintended lockouts | Keycloak alone if your release can evaluate this condition; confirm before relying on it |
| Session and credential revocation | Event-triggered on disable or password reset, or manual during an incident | Revoked sessions cannot be restored; users must sign in again | Keycloak alone for sessions and credentials it holds; external sessions need separate revocation |
| Access review reminders | Scheduled at a periodic interval | Reversible; reminders can be resent or stopped | Keycloak can send notices, but certification decisions belong to a governance system |
Where Keycloak workflows end and identity governance begins
Keycloak workflows should stop at the point where a decision needs an authoritative source, a named approver or evidence that someone reviewed access. Inside Keycloak, workflows can react to events and schedules by sending notifications and disabling accounts, which covers the mechanical part of a joiner, leaver or inactivity step. A full identity governance tool such as Evolveum midPoint takes on the decisions around that mechanical part. Before you design anything, list every lifecycle step your access policy requires and mark each one as either a mechanical action or a decision with a named owner. The second group is where the boundary sits.
A governance tool adds five things that Keycloak workflows do not provide on their own. The first is an authoritative HR source that determines who is a joiner, mover or leaver. The second is approval workflows for access requests that need a named approver. The third is certification campaigns, where managers or application owners attest to access on a defined schedule. The fourth is connectors that provision and reconcile entitlements in target systems beyond Keycloak. The fifth is reporting that shows who approved what, who certified it and when. Keycloak login and admin events can feed audit records, but they do not show that a manager reviewed a grant. Ask any vendor to demonstrate each of these against your own HR feed and target systems.
Keycloak workflows do not replace the decision about whether a person should hold access in the first place. They also do not reconcile roles across applications outside Keycloak, and they do not produce certification evidence by themselves. Keycloak remains the place where sign-in is enforced, sessions end and realm accounts are disabled, whatever upstream process made that decision. Confirm with your auditors which evidence they will accept for your access review control, and whether a record kept only in Keycloak meets it. If LDAP or Active Directory federation supplies some attributes, also confirm which system owns each attribute, because that determines who controls the account state.
One workable split gives the governance tool ownership of the identity record, the joiner and leaver decisions, approvals and certifications. It then pushes the resulting account state and group membership into Keycloak through an interface such as SCIM, which is covered in its own topic. Keycloak workflows handle the time-bound steps close to the account: notifying users ahead of an inactivity disable, disabling an account when a leaver has not yet been confirmed by the governance tool, and sending reminders. Decide which system prevails when the two disagree, then test a leaver case where the HR record and the governance tool conflict. Write the conflict rule down before go-live so operators know which system to trust.
How to set up Keycloak onboarding and offboarding steps
This sequence takes joiner, leaver and inactivity handling from a written policy to a monitored production rollout in Keycloak. It produces tested workflows, a verified notification path, and evidence that disabled accounts lose access and their sessions end. Each step closes with a check the team can record.
Confirm the Keycloak release and workflow status
Record the Keycloak release you will run, then check the server administration guide for that exact version to confirm whether workflows are available, how they are enabled, and whether any feature flags or preview labels apply. The current release is 26.8.1, published October 13, 2026, but your target version may differ, so confirm it against its release notes. Platform engineering owns this step. It is done when the team holds a written note with the version, the feature status and the documentation section it relied on.
Define joiner, leaver and inactivity policy
HR, application owners and the security team agree in writing on what triggers each event. The policy states when a joiner receives access, which applications and groups that access maps to, when a leaver loses access, and which period of inactivity leads to disablement. It also names who approves exceptions, such as contractors, sponsored accounts and service accounts. The step is done when every rule lists a trigger, an owner, an action and an exception path, and HR and each application owner have signed off.
Set the authoritative source of identity changes
Decide which system is the source of truth for employment status and group membership, typically HR or an identity governance tool. Document how changes reach Keycloak: through workflows that read existing user data, through API calls from the source system, or through a scheduled import. Keycloak workflows act on users that already exist in the realm, so account creation and attribute changes must originate from a system the team controls. Note here if the organization needs a full governance tool. The check is a data flow diagram showing where each attribute originates and which system takes precedence when two sources disagree.
Configure realm and user profile attributes
In a non-production realm, define the user profile attributes that workflow conditions depend on, such as employment status, department or sponsor, and set who can view and edit each one. Align groups and roles with the access model from the policy step. Make these changes through configuration export or as code where possible so the team can review them before they reach production. The check is a sample user created from a test HR record, with every attribute populated and group membership matching the policy.
Build and test workflows in a non-production realm
Create the joiner, leaver and inactivity workflows in a dedicated test realm, using the trigger, condition and action types your Keycloak version provides. Keep each workflow to one purpose, name it after its policy rule, and run it against seeded test users that cover a standard employee, a contractor, a user on leave and a service account. Confirm that the expected action fires once per event and that a user who does not meet the condition is left unchanged. The check is a test log for each workflow that shows both outcomes.
Verify notification delivery over StartTLS
Configure the SMTP server used for workflow notifications to meet the enforced StartTLS behavior introduced in Keycloak 26.8, which does not allow plaintext fallback. Confirm with your mail team that the relay supports StartTLS, that its certificate is trusted by the Keycloak hosts, and that the sending account is authorized to relay. Send a test notification from each workflow path and review the server logs. The check is that every test message travels over an encrypted session, and that a deliberate misconfiguration produces an error the team can see.
Verify disabling, session revocation and event logging
Enable user and admin event logging before testing, so each action leaves a record. Using test accounts, run the leaver and inactivity workflows, then sign in as the test user in a browser and from an API client that holds a token. Confirm that the account is disabled, that existing sessions end, and that new sign-in attempts fail. Also confirm which token lifetimes apply, since a token issued before disablement may remain valid until it expires. The check is that the events for each action are stored and searchable in the admin console.
Roll out with rollback and monitoring in place
Promote the tested workflows to production in a planned change window with a written rollback plan. The plan disables the workflow definitions, restores the previous realm configuration from an export, and names who can reverse a disablement. Start Keycloak with metrics enabled on its management interface, and set alerts for failed sign-ins and unexpected changes in the number of disabled accounts. The check is a rollback rehearsed in a test realm, an operations dashboard the team can read, and a named owner for the first review of workflow results.
Security controls for automated joiner and leaver steps
Workflows can disable accounts, change access and send notices at scale, so the controls around them matter as much as the steps themselves. The six controls below cover who runs workflows, how the admin surface is exposed, what gets recorded, how changes roll out, who can edit workflows, and how the platform is monitored.
Least-privilege service accounts
Each workflow runs with the permissions of the identity that executes it, so that identity should hold only the realm management roles its steps require. Create a dedicated service account for each group of workflows instead of sharing one administrator account across all of them. Confirm which identity a workflow action runs under in your Keycloak version, and review the assigned roles after every upgrade, because required permissions can change between releases.
Admin access and TLS
The production guide calls for TLS on all communication and for exposing the admin console and Administration REST API on a different hostname or context path from public frontend URLs. Place a reverse proxy in front of Keycloak with path restrictions so the admin paths are reachable only from management networks. Verify encryption on each connection, including the database and mail server, and note that Keycloak 26.8 enforces SMTP StartTLS without plaintext fallback.
Audit trails from admin and login events
Admin events record changes made through the console and REST API, and login events record authentication activity. Enable both in the realm event settings, decide whether representations are stored, and set retention to match your audit policy. Test that a workflow-driven disable action produces an admin event you can trace to the workflow run, then forward events to your SIEM through the Listener SPI.
Staged rollouts against mass disablement
A leaver rule with a wrong attribute filter can disable a large share of accounts in a single run. Roll out disable actions in stages: start with notify-only steps, then a small filtered population, then the full scope. Confirm whether your version offers a preview of matched users. If it does not, export the matched set and review it before enabling the disable step.
Separation of duties for workflow edits
Anyone who can edit a workflow can change who gets disabled, so authoring, approval and realm administration should sit with different people where your team is large enough to split them. Limit edit rights through fine-grained admin permissions or dedicated roles where your version supports them. Keep a change record for each workflow revision, and confirm which admin roles can create or edit workflows before granting access.
Monitoring through the metrics endpoint
Keycloak exposes Prometheus-format metrics at /metrics on its management interface when started with the metrics flag enabled. Scrape that endpoint from your monitoring stack, restrict who can reach it, and alert on unusual login failure or request volume. Confirm whether workflow runs emit their own metrics in your version before relying on them for alerts.
What happens to sessions, federated users and credentials at offboarding
Disabling a user in Keycloak stops new logins for that account, but it does not, by itself, end every way a former employee can still reach your applications. A leaver workflow should be designed around the paths a person can use to get in or stay in, and each path needs its own check. Start by listing them: active sessions and tokens, federated sources, brokered identities, passkeys and OTP credentials, recovery codes, and organization memberships. Treat that list as the scope of your offboarding test, not as a set of assumptions.
Active sessions and tokens come first. A disabled user may still hold a browser SSO session or refresh tokens that were issued before the change. Confirm in the Keycloak server administration guide how sessions are terminated for a user, whether the admin console and Administration REST API both support it, and whether access tokens already issued remain valid until they expire. Then decide whether your lifetimes for access tokens, refresh tokens and SSO sessions are short enough for your risk tolerance, and whether your workflow must also trigger backchannel logout to registered clients.
Users sourced from LDAP or Active Directory federation need a different treatment. When the directory record controls login, disabling the Keycloak copy may be overridden by the next sync, or the user may simply be re-imported. Your leaver step has to act on the source record or on the federation mapping, and you should test what happens when the directory account is disabled but the Keycloak account still exists. Check how the federation provider handles deleted and disabled entries during synchronization, and confirm the expected behavior with a test account in a non-production realm before relying on it.
Users who sign in through brokered identity providers, whether OIDC, OAuth, SAML or social providers such as Google or Microsoft, can often re-authenticate successfully after a Keycloak account is disabled if the brokering flow creates or links accounts again. Decide who owns the external identity, disable or unlink the broker link where appropriate, and confirm in the administration guide how first-broker-login and linked identities behave. For passkeys, OTP credentials and recovery codes, remove or reset the credentials as part of the leaver step, because a stored second factor can outlast the account's usefulness. Test each credential type on a test user and record what the user sees after the change.
Finally, coordinate with downstream applications. Any application that caches sessions, keeps its own local user record, or issues its own tokens after a Keycloak login may continue to grant access until its cache expires. Organization memberships also need review, since a leaver may still belong to a managed organization with its own domain rules. Document the expected end state for each path, run every test with a test account, and agree with application owners on how quickly each system must reflect the change. Ask your implementation partner or internal team to confirm these behaviors against your Keycloak version before go-live.
Limits to confirm before you commit to Keycloak workflows
Workflow capabilities change between releases, and the limits that matter for joiner, leaver and inactivity steps depend on your topology and user volume. Each card names one limit and what to confirm in the vendor documentation or a test environment before you rely on it.
Feature availability and maturity
Confirm that the workflow capability you need exists in the exact release you will run, and whether it is marked stable, preview or experimental. Keycloak plans four minor releases a year, so a feature shown in a demo may differ from your version. Check the release notes and the server administration guide for your version, and ask whether the feature needs an explicit enable flag before it appears in the admin console.
Supported triggers and actions
List every event that can start a workflow, such as a user being created, a login, or a scheduled run, and every action it can take, such as sending a notification or disabling an account. Joiner, leaver and inactivity processes each depend on specific triggers, and a missing one forces a custom extension or a separate external job. Ask whether you can add a custom action and who maintains it after each upgrade.
Calls to external systems
Onboarding often needs a ticket, an HR confirmation or an asset record in another system, and offboarding needs the same systems to revoke access. Confirm whether a workflow step can call an HTTP endpoint, how it authenticates, and whether it can wait for the response. Then test timeout behavior, because a slow or unavailable downstream system can stall a leaver workflow that must finish quickly.
Clustered, multi-site and rolling upgrades
Confirm which cluster node runs a scheduled step when several members are up, and whether the same step can fire twice. Keycloak's supported high availability designs both need a synchronously replicated database, and the 26.8 upgrade notes recommend moving from the deprecated multi-site feature to the stateless feature. Test workflows during a rolling upgrade, including steps that are queued or half-finished when a node restarts.
Timing and throughput for large populations
A scheduled inactivity sweep over a large user base can run longer than the window you planned and compete with sign-ins for database and cache capacity. Ask how the workflow processes users in batches, whether it slows under load, and how long a full pass takes. Measure this in a test environment with a copy of your population size, and watch the Prometheus metrics the server exposes when metrics are enabled.
Retries, reporting and exports
Confirm how a failed step is retried, how many attempts occur, and whether the workflow then stops, skips or escalates. Check where failures appear, such as admin events, server logs or a report an auditor can read. Then ask whether workflow definitions can be exported as files and stored in version control, so changes to a leaver process can be reviewed and rolled back.
Keycloak user onboarding and offboarding questions buyers ask
What drives the cost of a Keycloak onboarding and offboarding build?
Cost follows the systems and rules in scope more than headcount alone. Main drivers: the number of joiner, mover and leaver events the workflows must handle, how many target applications and groups change, how HR data reaches Keycloak (SCIM, file or API), how many approval and notification paths exist, and how many environments need testing.
One-time costs cover discovery, design, build, testing and handover. Recurring costs cover upgrade testing, workflow changes when policy changes, and monitoring. Ask for a quote that lists each deliverable, the environments covered, who performs testing, which items are optional, and which costs you carry internally. DeployOpen does not publish prices. A quote follows from the written scope.
How long does a scoped Keycloak lifecycle workflow build take?
Duration depends on the scope, the readiness of your inputs and the number of environments that must be validated before production. A typical scoped build moves through discovery, design, build, test and handover, and each phase depends on decisions from your teams.
The biggest delays usually come from unsettled HR data definitions, approval paths nobody has agreed, application owners who have not confirmed group mappings, and change windows. Ask for duration as milestones with named dependencies on your side, not as a single figure. Any estimate given before the scope is agreed is a planning assumption, so ask which assumptions it depends on and check them against the deliverables list.
What do we need from HR, application and security teams for this work?
HR must identify the authoritative source for joiners, movers and leavers, the fields it provides, and the timing of changes such as contract start dates and terminations. Application owners must confirm which groups, roles and client settings each joiner should receive, and which accounts must be disabled or reassigned when someone leaves.
Security must approve who can trigger or override a disable action, how notifications are routed, how events are retained and reviewed, and what emergency access looks like. Your Keycloak administrators need to provide a non-production realm, a test identity source and an account for the workflow service identity. Agree these owners in the written scope, because most schedule slips come from decisions that were never assigned to a named person.
Can our own identity team build Keycloak onboarding and offboarding workflows?
Often yes, if your team already administers Keycloak realms, clients and user federation, can test in a non-production instance, and has capacity for ongoing upgrades. Keycloak is licensed under Apache 2.0, so the server itself carries no license purchase, and the cost is in people, testing and maintenance.
A partner adds value when deadlines are fixed, when the team lacks workflow or scripting experience, or when several HR and application sources must be integrated at once. Before deciding, confirm in your specific Keycloak version which workflow triggers, actions and schedules are available and how they behave, because that determines how much custom work remains. A written scope lets you compare your internal estimate with an external quote on the same deliverables.
How do Keycloak workflows differ from SCIM provisioning and identity governance?
SCIM provisioning moves user and group records into Keycloak from a source system through an API, so it answers the question of which accounts exist and what attributes they carry. Keycloak workflows run steps inside Keycloak when an event happens or a schedule fires, such as notifying a manager or disabling an inactive account. Identity governance tools handle access requests, role models, approvals and periodic access certification across many systems.
In practice, provisioning often feeds the directory, workflows act on what changed, and governance decides who should hold access in the first place. Confirm which system owns each decision in your design, because overlapping disable actions in two tools cause confusion during audits and incidents. The SCIM provisioning topic covers the API side in more detail.
What ongoing work follows go-live, such as Keycloak upgrade testing?
Keycloak ships on a regular cadence. According to the Keycloak blog from October 2024, the project has planned four minor releases a year since 26.0, with a major release every two to three years, and breaking changes in minor releases are opt-in. The current release is 26.8.1, published October 13, 2026, so plan for upgrades as recurring work.
After go-live, budget for re-testing each workflow after upgrades, reviewing upgrade notes for changed defaults, checking database schema migration (automatic at startup by default, with manual migration often used for large deployments), and keeping the Operator on manual approval if you deploy with it, as its documentation recommends. Add monitoring through the metrics endpoint and periodic reviews of workflow logs. Ask for these items as a separate retainer or support line in the quote.
What should a written scope and quote for this work include?
A usable scope lists the lifecycle events covered (joiner, mover, leaver, inactivity), each source system and data field, each target realm, client and group, and the notification and disable actions. It names the environments, the acceptance tests and who signs them off, and it defines handover documents such as runbooks and configuration records.
The scope should also state assumptions, client responsibilities with owners, exclusions such as governance workflows or custom code outside the listed actions, change control for new requirements, and support options after go-live. Milestones should carry dependencies on your teams. A quote is only comparable to another if both cover the same deliverables, so ask each provider to map their line items to the same scope document.
What should we test before enabling leaver steps in production Keycloak?
Test leaver steps with dummy accounts in a non-production realm that mirrors your production configuration, including groups, client mappings and mail settings. Confirm what a disable action does to active sessions, refresh tokens and any offline tokens the account holds, and document how that behaves in your Keycloak version.
Verify that notifications are delivered through your mail relay. If you run Keycloak 26.8 or later, note that the upgrade notes enforce SMTP StartTLS without plaintext fallback, so an older relay configuration may fail silently. Check that events are recorded in your audit trail, rehearse a reversal for a wrongly disabled account, and confirm who is authorized to override a step. Record the results as acceptance evidence before the change window.
How DeployOpen scopes, builds and supports Keycloak lifecycle automation
DeployOpen plans, builds and supports Keycloak workflows for user onboarding and offboarding inside infrastructure you control. Each engagement starts from a written scope that names the joiner, leaver and inactivity steps, the systems they touch and the people who approve them. Work is delivered as a fixed-scope engagement, with ongoing support available as a retainer.
How we scope
- The written scope lists each joiner, leaver and inactivity step and the Keycloak realm, clients and roles it touches.
- We agree which events trigger a workflow, which run on a schedule, and which need a human approval.
- Scope also records which systems stay authoritative for identity data, such as an HR source or directory.
How we build
- We configure notify and disable steps, then test each path with sample accounts in a non-production realm.
- Where a workflow cannot express a rule, we document the gap and the step that covers it.
- Service account permissions are limited to the user and role operations each workflow needs.
How we hand over
- Handover includes exported realm configuration, workflow definitions and a runbook for each joiner, leaver and inactivity path.
- Test records show which accounts were tested, the expected result and the observed result for each path.
- Your team receives the change procedure for workflow edits, so later changes go through the same review.
How we support
- Retainers can cover Keycloak upgrades, workflow changes and periodic review of the lifecycle rules.
- Upgrade planning checks workflow behavior against the release notes for each Keycloak version you adopt.
- Operational checks for scheduled runs are agreed in scope, using the metrics Keycloak exposes where they fit.
