Identity is rarely a project of its own. It usually becomes a topic when a third application appears and nobody can say where user accounts actually come from any more.
Typical starting situations
- Several applications each manage their own users.
- A directory service exists but is only partly treated as the source of record.
- An existing SAML integration needs to move to OpenID Connect without an outage.
- The identity service has become central but was never designed for failover.
The technical work
- Setting up, operating and integrating Keycloak in existing landscapes
- Defining realms, clients, role models and token lifetimes
- Connecting LDAP as the source of record for users and groups
- Planning and staging migrations from SAML to OIDC
- Automating account provisioning and deprovisioning via SCIM
- Documenting failure behaviour and operational boundaries before they are tested
How we approach it
The role model comes before the configuration. Who may do what, and who decides that? A technically sound identity service with an unclear role model only relocates the problem.
Migrations are planned with a period of parallel operation. Cutting every application over on a single date is rarely necessary and almost always riskier than it needs to be.
System context
For identity services, high availability is an architectural decision rather than a configuration switch — particularly around session handling and the database. The article Running Keycloak in high availability covers the decisions involved.