From ForgeRock to Keycloak

ForgeRock is now part of Ping under Thoma Bravo, and the pricing reflects it: enterprise per-user licensing across AM, DS, IDM, and IG. The acquisition also brought roadmap uncertainty, and for many teams that, as much as the per-user and per-module cost, is what puts a migration on the table. Keycloak is the open-source destination teams reach for when the directory is not gigantic and the orchestration is not exotic. Identity is the one system you cannot afford to break, so this migration is all about parallel-running and a phased relying-party cutover, never a flag day.

Two decisions dominate the effort and both are covered below: how much of your orchestration lives in bespoke journey nodes, and how you handle the DS password hashes. Get an honest read on those two before you commit a timeline, because they, not the routine client re-registration, are what stretch the schedule.

Realm and client modelling

Keycloak’s organising unit is the realm. Recreate each relying party as a Keycloak client, SAML clients for SAML apps, OIDC clients for the modern ones. Map the ForgeRock pieces like this:

• AM realm → Keycloak realm. Keep tenant boundaries the same.
• OAuth2/OIDC clients and SAML entities → Keycloak clients, re-registered one per app.
• AM policies / authorization → Keycloak roles, groups, and (where needed) authorization services.
• DS (DJ) directory → user federation rather than a one-shot copy.
• IDM provisioning → SCIM and the admin REST API.

Exchange SAML metadata and signing certs per app, and add protocol mappers so a relying party that expected a specific ForgeRock claim still receives it under its mapped name.

Journeys become authentication flows

This is the conceptual core. ForgeRock Intelligent Access journeys (trees of nodes: username collect, password, push, risk, MFA) translate to Keycloak authentication flows: ordered executions with REQUIRED, ALTERNATIVE, and CONDITIONAL semantics, grouped into subflows.

A journey that does “username, then risk check, then conditional MFA” becomes a flow with a conditional subflow keyed on a user attribute or a role. Simple to moderate journeys map directly. Anything that leaned on bespoke scripted nodes or a marketplace node becomes a custom Authenticator SPI in Java that you build and maintain. Inventory your nodes early; the count of custom and scripted nodes is the best single predictor of migration effort.

Federating the directory

Keep ForgeRock DS authoritative during transition and point Keycloak at it:

• LDAP user federation against DS, mapping attributes and group DNs.
• SCIM or admin-API import when you want users native in Keycloak from day one.

Federation lets you run both IdPs against one source of truth while you cut apps over, which is exactly what you want.

The password hash problem

DS stores salted hashes (often PBKDF2 or bcrypt variants). You have two realistic paths:

• Custom hash provider. Implement a Keycloak PasswordHashProvider SPI that understands the DS hash format so imported users authenticate on first login with no reset. This is the smooth path and worth the Java effort for large user bases.
• Forced reset. Cut over and email everyone a reset link. Cheap to build, heavy on users and the help desk.

A skeleton hash provider registers via the standard SPI:

public class DsPbkdf2HashProvider implements PasswordHashProvider {
    @Override
    public boolean verify(String rawPassword, PasswordCredentialModel credential) {
        // re-derive using the DS salt + iteration count, constant-time compare
    }
}

Register it in META-INF/services and drop the JAR in providers/, then kc.sh build.

Phased cutover, both IdPs live

1. Stand up Keycloak in HA: multiple nodes, external PostgreSQL, tested upgrades and backups.
2. Federate DS, recreate clients, build the flows and any custom authenticators.
3. Solve the password path before any app moves.
4. Move relying parties one group at a time, validating tokens, claims, group authorization, and MFA at each step.
5. Run ForgeRock and Keycloak in parallel until the last app is migrated and the on-call team trusts it through a real incident.

Where ForgeRock still wins

Do not migrate if these describe you:

• Very large-scale directory. DS scales to tens of millions of entries with replication topologies Keycloak does not match comfortably. Keycloak fronts a big directory better than it owns one.
• Complex orchestration. Deep risk-based, step-up, and identity-proofing journeys with many scripted nodes are far more expressive in ForgeRock than in Keycloak flows.
• Identity Gateway (IG). Reverse-proxy enforcement, header injection, and protecting legacy apps with no modern protocol is an IG strength with no clean one-to-one in Keycloak.
• Vendor support and HA. ForgeRock ships supported HA reference architectures. With Keycloak, the clustering, the database, and the 03:00 page are yours.

Where this nets out

ForgeRock to Keycloak removes enterprise per-user licensing in exchange for owning your IdP. Realms, clients, and federation are routine; the real effort is translating journeys into flows (and any scripted node into a custom SPI) and choosing a password-hash path, ideally a custom provider over a forced reset. Keep both IdPs live and cut over per group. Model the per-user saving in the calculator above, and discount it by the engineering time to run HA and rebuild orchestration you currently get off the shelf.