What Is Identity Management? Lifecycle and Keycloak

Identity management is the practice of administering digital identities, including their accounts, attributes, authenticators and access privileges. This lifecycle definition combines the administration of identities, roles and privileges described in the NIST identity and access management glossary with the creation, maintenance and termination of accounts in NIST’s subscriber account guidance. When a user joins, changes roles or leaves, your identity process should update the connected applications through the integrations you configure; synchronization is a goal to verify, rather than an automatic property of identity management.

If you have inherited a login system, you also need to understand where its accounts come from and what happens when someone changes jobs or leaves. We will connect that vocabulary to Keycloak users, directories, provisioning and groups, then walk through a test user’s lifecycle.

Key takeaways

• Identity management includes account creation, maintenance and termination, as described in NIST’s account guidance.
• We use access management to mean authentication and authorization; both sit inside IAM.
• Directory federation reads existing directory identities, while SCIM provisioning manages resources in a receiving system.
• A useful lifecycle test checks creation, changed access and retirement in each connected application.

What is identity management managing?

A subscriber account is a system’s record of a person, their attributes and associated authenticators, as described in NIST’s Digital Identity Guidelines. In our example, that record includes a username, email address and department. NIST defines an authenticator as something the subscriber possesses and controls, such as a password or a device holding an authentication key, used to authenticate their identity.

Those pieces have different jobs: NIST’s subscriber account guidance distinguishes the account’s unique identifier, attributes and bound authenticators. For Alex, use department as an input to your access policy, and require authentication before accepting that the person at the login screen controls Alex’s account.

For a running example, imagine a test employee named Alex who joins engineering, later moves to support and eventually leaves. The identity record should follow those changes, while the permissions attached to it should match Alex’s current responsibilities. Creating a working login is only the beginning of that exercise.

Identity management vs access management vs IAM

For this guide, we separate identity record maintenance from authentication and authorization, meaning deciding which actions are allowed. Microsoft’s IAM concepts guide describes identity management, authentication and authorization as responsibilities within identity and access management, or IAM. The NIST IAM glossary includes both identity administration and management of access privileges, so the terminology overlaps.

This distinction is useful when investigating a problem. For a missing account, start by checking provisioning and directory lookup; for a signed-in user who cannot open a page, start by checking authorization rather than treating either symptom as a diagnosis. An identity provider, or IdP, is the service that authenticates users and supplies identity information to applications. Our identity provider introduction explains that component in more detail.

The joiner, mover and leaver lifecycle

Joiner, mover and leaver describe the events your identity process needs to handle. Use them as an acceptance checklist for your own system, with an expected result for each application. The underlying account creation, maintenance and termination responsibilities are described in NIST’s subscriber account guidance and its account lifecycle requirements.

Our joiner, mover and leaver process guide explains how to organize this flow across your applications.

• A joiner needs an account and appropriate starting access. Decide which source establishes the person’s identity, which attributes you need and how they register their initial credentials.
• A mover needs revised attributes and access. When Alex moves to support, remove access tied to engineering and add the support permissions the new job requires. Check for old permissions explicitly instead of treating the new assignment as evidence that the old access was removed.
• A leaver needs access removed across connected systems. Disable the account, handle active sessions and retire any separate application accounts. Decide when to delete the identity according to your retention policy and the records that still reference it.

For this exercise, write down which system owns each change. Your employee directory might own department membership, while an application owns permissions for its records. Treat that ownership map as a practical design decision: without it, you cannot tell which system should correct an inconsistent account.

Keycloak examples of identity management

Keycloak is an open-source identity and access management project that the Cloud Native Computing Foundation accepted at the Incubating maturity level in April 2023. Its user model lets you see how identity records and access settings relate. The following examples use a test realm and an illustrative local user; directory-backed accounts need additional checks described below.

Users and attributes in a realm

The core concepts section of the Keycloak Server Administration Guide describes a realm as an isolated container for its users, credentials, roles and groups. You create a user within that realm. A user’s attributes describe the account, and the user profile section explains how to configure them from the User Profile tab under Realm settings in the Admin Console. The same guide describes required actions as steps users must complete while authenticating, such as updating a password, and its procedure for one user sets them from the user’s Required User Actions list.

For Alex, start with a username and email address, then decide whether a department attribute is needed. Use the realm’s user profile configuration to define custom attributes rather than assuming that a value entered in one system will appear everywhere. If you run Keycloak on Skycloak, the same realm users appear in our dashboard: the user management feature page describes what it covers, and the user management documentation walks through creating users, assigning realm and client roles, organizing users into groups and monitoring active sessions.

Federation to LDAP and Active Directory

User federation connects Keycloak to an existing identity store. Keycloak’s LDAP and Active Directory provider lets a realm read users from LDAP directories and map their attributes into Keycloak’s user model. LDAP is the Lightweight Directory Access Protocol, and Microsoft’s protocol summary identifies Active Directory as an LDAP server.

The provider’s Import Users switch controls whether Keycloak stores a local copy of a directory user. Its Edit Mode setting controls how changes are handled, as explained in the same section:

• In READ_ONLY mode, you cannot update mapped directory attributes or passwords through Keycloak.
• In WRITABLE mode, changes to mapped attributes and passwords are written back to LDAP automatically.
• In UNSYNCED mode, Keycloak keeps changes in its local storage. If you need those changes in LDAP, the administrator must arrange to synchronize them back.

For Alex’s directory-backed account, check which attributes and memberships your mappers transfer. Keycloak’s LDAP mappers map directory attributes and groups to its user model. Follow our LDAP integration guide or Active Directory integration guide for a setup walkthrough. Federation is different from brokering, where Keycloak sends the login to an external identity provider and, as the brokering overview explains, usually receives a security token to verify the authentication and obtain user information; our identity providers feature page shows how you can connect external identity providers.

Do not assume that a generic LDAP synchronization job transfers account-disable state. Keycloak documents an MSAD User Account Mapper for translating Active Directory account state, including disabled accounts and expired passwords, into Keycloak account state. The same section identifies userAccountControl and pwdLastSet as the Active Directory attributes it reads. That behavior depends on the mapper being present and configured, so test a disabled directory user against your actual login flow before relying on it for offboarding.

Provisioning in and out with SCIM

Provisioning means creating and maintaining accounts in a target system. SCIM, the System for Cross-domain Identity Management, standardizes those operations over HTTP. The SCIM protocol specification defines creation, retrieval, replacement, partial updates and deletion of user and group resources, while the core schema defines identity attributes, including administrative status through active.

Keycloak includes a native SCIM API. The Keycloak 26.8.0 release notes mark its transition from preview to supported, and the upgrading guide confirms that the scim-api feature is enabled by default. The SCIM section of the server administration guide explains the additional step for each realm: open Realm settings > General, turn the SCIM API toggle on and save. Check your deployed version before configuring a connector; our SCIM release walkthrough explains the change, and the SCIM provisioning feature page describes SCIM provisioning on Skycloak.

The direction matters here: the SCIM introduction in the same guide describes external identity governance platforms, HR systems and identity providers provisioning users into Keycloak, so Keycloak is the receiving SCIM server in this example. The same introduction limits these operations to users and groups inside a realm; do not treat creation in that realm as proof that Alex has an account in a downstream application. For outbound provisioning, identify the connector or separate tool that writes to each application’s account store, then test its update and retirement behavior. Our free SCIM endpoint tester lets you build SCIM provisioning requests, validate SCIM 2.0 schema compliance and generate ready-to-run cURL commands while you work that out.

Groups and roles for access

Groups organize users. The Keycloak documentation on managing groups explains that a user can join multiple groups without a membership limit and receives each group’s attributes and role mappings. Roles express categories of access: the chapter on assigning permissions using roles and groups describes realm-level roles as “a namespace for defining your roles” and client roles as “namespaces dedicated to clients”, where a client is an application registered in the realm.

For our test, create engineering and support groups and give each a different application role. Put Alex in engineering, then move Alex to support. Check the application’s actual authorization decision after the move, including whether Alex still has any directly assigned roles. Our Keycloak RBAC guide explains role-based access control, where application permissions depend on assigned roles.

Run the lifecycle in a test realm

Use a local test user first so you can isolate account changes from directory configuration. The examples below assume that your Keycloak Admin CLI is installed and authenticated as an administrator who can manage users in the test realm. They illustrate documented Admin REST API user operations through the Admin CLI.

Create the joiner’s account

Create Alex in an existing test realm named lifecycle-demo. The command follows the Admin CLI user creation example in the Keycloak documentation, and we capture the new user’s identifier into a shell variable with the -i option the same way the Admin CLI introduction captures a client’s identifier. This command creates the record only; configure credentials and group membership separately before attempting a login.

USER_ID=$(kcadm.sh create users -r lifecycle-demo \
  -s username=alex -s email=alex@example.com \
  -s enabled=true -i)

If you prefer the Admin Console to the command above, select lifecycle-demo, open Users > Add User, enter alex and alex@example.com, then click Save, following the user creation procedure. Use either method to create the account, then open Users > alex > Credentials and use the Set Password section to set a temporary password for the test login.

Add Alex to engineering through Users > alex > Groups > Join Group, select engineering and click Join, following the group membership procedure, then sign in to a test application. Record which actions succeed and which are denied, so you have something concrete to compare after the move.

Update the mover’s access

Remove engineering membership and add support membership. In the Admin Console, open Users > alex > Groups, click Leave on the engineering row, then click Join Group, select support and click Join, following the group membership procedure. The Admin REST API exposes group membership as a PUT and a DELETE on the same path, documented under its users resource, and the Admin CLI documentation shows the same calls under adding a user to a group. Substitute the actual group identifiers you recorded in the console:

ENGINEERING_GROUP_ID='replace-with-engineering-group-id'
SUPPORT_GROUP_ID='replace-with-support-group-id'

kcadm.sh delete "users/$USER_ID/groups/$ENGINEERING_GROUP_ID" \
  -r lifecycle-demo
kcadm.sh update "users/$USER_ID/groups/$SUPPORT_GROUP_ID" \
  -r lifecycle-demo -s realm=lifecycle-demo \
  -s userId="$USER_ID" -s groupId="$SUPPORT_GROUP_ID" -n

The Admin CLI documentation explains that update normally reads the existing resource before merging changes, while -n sends a PUT directly without that initial GET. Start a fresh application login and confirm that Alex can perform the support actions and cannot perform the engineering actions. Also test an existing session, because the result tells you whether the application notices changed access without a fresh login.

Disable the leaver and end sessions

For this local user, disable the account and invoke the user logout endpoint. The Admin REST API’s users resource documents POST /admin/realms/{realm}/users/{user-id}/logout as ending the user’s sessions and notifying clients that have an admin URL to invalidate their sessions for that user. The Admin CLI documentation shows the same call under logging out a user from all sessions. The disable command follows the Admin CLI’s updating a user example and sets the enabled field, which the user representation lists as a Boolean:

kcadm.sh update "users/$USER_ID" -r lifecycle-demo -s enabled=false
kcadm.sh create "users/$USER_ID/logout" -r lifecycle-demo \
  -s realm=lifecycle-demo -s user="$USER_ID"

Check a new login, the existing application session and a previously issued access token separately. Keycloak access tokens are signed JSON Web Tokens, or JWTs, that an API can validate locally using the issuing realm’s public key, as described in its guide to OpenID Connect endpoints. Local validation alone should not be treated as a check of Alex’s current account state. Review the realm’s Access Token Lifespan, which sets the token’s validity duration, and test whether your API still accepts a token after disabling Alex. The same guide describes introspection as an endpoint for retrieving a token’s active state. If you need current server-side token status, evaluate that request alongside any application-specific revocation checks rather than assuming that local validation detects an account change.

Repeat the exercise for every connected application account. For directory-backed users, disable the identity at its authoritative source and verify the configured mapper’s result in Keycloak. For SCIM, verify your connector’s deactivation behavior rather than assuming that an active update also handles sessions and downstream accounts.

Frequently asked questions

Is identity management the same as a login system?

A login system checks credentials at authentication time. Account administration also handles the account before and after that login: NIST’s Digital Identity Guidelines describe enrollment and authenticator binding, while the subscriber account requirements cover updates, suspension and termination.

Does SSO replace provisioning?

Single sign-on, or SSO, lets a user authenticate through a shared identity service. Provisioning manages the account record in a target system. You still need to decide how each application creates and retires its records, even if login is centralized. SCIM’s protocol specification defines the account-management operations.

Does deleting a Keycloak user delete their application data?

Treat application data retirement as a separate task. Keycloak’s user deletion instructions describe removal of the user’s profile and data when you delete the user in Keycloak. Check where each application keeps records such as orders, tickets or files, and verify its retention and deletion behavior before removing an identity it references.

Try the lifecycle yourself

Start with a test user, groups and a connected application, then repeat the exercise with your real provisioning source. Keep a record of which system owns the identity, how changes reach each application and how you verify that departed users lose access.

Start from the pricing page and follow the account setup guide to select the Expert trial path, which provides a dedicated cluster with Admin Console and kcadm access for this exercise. Then federate a directory, create Alex, move Alex between groups and disable the account. Identify how each downstream application receives account changes, and test each integration and application separately, including account updates, retirement and session handling. Our user management screens let you create the user, change the group membership and inspect active sessions along the way.

Sources and documentation versions

The Keycloak Server Administration Guide identifies its version as 26.8.0. Its latest links can change; compare them with the documentation for your deployed version before running the examples.

• NIST: IAM glossary, Digital Identity Guidelines, SP 800-63-4 and Subscriber Accounts, SP 800-63A-4.
• Microsoft Learn: Identity and access management concepts.
• Keycloak: Server Administration Guide, Admin REST API reference, release notes, upgrading guide and OpenID Connect endpoints and token validation.
• IETF: SCIM protocol, RFC 7644 and SCIM core schema, RFC 7643.
• CNCF: Keycloak project profile.
• Skycloak: account setup, service overview, user management documentation, user management feature, identity providers, SCIM provisioning, SCIM endpoint tester and managed Keycloak hosting.