Ping Identity is a mature enterprise IdP, but per-user pricing layered with per-module add-ons (federation, MFA, directory, access management bought separately) gets expensive and complex as you grow. Keycloak, the open-source identity and access platform now under CNCF stewardship, gives you SAML, OIDC, federation, MFA, and fine-grained authorization with no per-user fee. The trade is that you run, patch, and scale it yourself. 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.
The licensing is worth naming precisely, because it shapes what you are actually buying back. Ping charges per user, then adds per-module fees across a suite that spans federation, MFA, directory, and access management, so the true cost is spread across several line items and grows on two axes at once: more users and more modules. That complexity is part of the reason teams look to consolidate. Keycloak folds those capabilities into one open-source platform with no per-user or per-module meter, and the money you stop spending on licences is redirected into the engineering time to run it in HA. The calculator above is where you set the removed licensing against that operational cost.
Model the realm and clients first
Keycloak’s organising unit is the realm. Most organisations want one primary realm for the workforce (mirror separate Ping environments as separate realms only if you truly need isolation). Inside it:
- Recreate each relying party (your apps) as a Keycloak client, SAML clients for SAML apps, OIDC clients for modern ones. Carry over entity IDs, ACS/redirect URIs, and signing settings exactly.
- Map Ping’s policies/adapters to Keycloak authentication flows and client scopes.
- Recreate MFA as Keycloak required actions / OTP / WebAuthn policies.
Get the client definitions right and most of the migration is just pointing apps at a new issuer.
Re-registering relying parties in detail
Re-registration is the bulk of the routine work, and it is coordinated, not one-sided. For each SAML relying party you create a SAML client in Keycloak, carry over the entity ID and ACS URL, and exchange metadata and signing certificates so the app trusts Keycloak instead of Ping. For OIDC apps you recreate the client, its redirect URIs, and its scopes. In both cases the failure mode is silent: an app that expected a specific attribute or claim from Ping will accept a login from Keycloak but then behave wrongly if the value is missing or renamed. So before you move any app, diff a real assertion or token from Ping against what Keycloak issues, and add protocol mappers until they match. Keep the app pointed at Ping until that diff is clean.
Mapping Ping’s adaptive policies to authentication flows
Ping’s strength is adaptive, policy-driven authentication, and translating it is the conceptual core of this migration. In Keycloak the equivalent is the authentication flow: an ordered set of executions marked required, alternative, or conditional, arranged into subflows. A policy that does “collect username, evaluate risk, then require MFA only under certain conditions” becomes a flow with a conditional subflow keyed on a user attribute, role, or context.
The dividing line is how bespoke your Ping policies are. Standard risk-and-step-up logic maps directly onto flows. Policies that leaned on custom adapters, scripted rules, or signals Keycloak does not evaluate natively become custom authenticators you build in Java against Keycloak’s SPI and then maintain. Inventory those non-standard policies first: their count, far more than the number of apps, is what determines how much genuine engineering this migration carries.
The hard part: users and passwords
Provisioning identities has two routes, and you’ll likely use both:
- LDAP/AD federation. If Ping fronts an LDAP/AD directory, point Keycloak’s User Federation at the same directory. Users and credentials stay where they are and Keycloak federates them, often the cleanest path with no password migration at all.
- Bulk import (SCIM/export). Where identities live in Ping’s own store, export users and import them. Passwords are the catch: you generally cannot read them back out in plaintext. Two options, (a) write a Keycloak custom hash provider that understands Ping’s hash format so existing hashes validate on first login, or (b) import users without credentials and force a one-time reset/enrolment. Pick based on whether a forced reset is acceptable to the business.
Cut over relying parties one at a time
- Stand up Keycloak (HA: clustered nodes + a real database; do not run identity on a single box).
- Federate or import users and validate a test account end to end (login, MFA, group/role claims).
- Re-point one low-risk app from Ping to the Keycloak client; verify SSO, claims, and logout.
- Run both IdPs in parallel and migrate apps in waves, highest-risk last.
- Decommission Ping only after the final relying party is moved and you’ve confirmed token/claim parity.
Where this quietly goes wrong
- Claim/attribute mapping is where SSO silently breaks, an app expecting a specific SAML attribute or OIDC claim name needs a matching Keycloak mapper. Diff the assertions Ping issued against Keycloak’s before cutover.
- Session and logout semantics (SLO, back-channel logout) differ; test logout, not just login.
- Token lifetimes and refresh defaults differ from Ping, align them so app sessions don’t behave unexpectedly.
- HA and upgrades are yours now. Keycloak is free, but production identity means clustering, database HA, backups, and a patch cadence. Budget the operational time, or buy commercial support (e.g. Red Hat build of Keycloak).
The takeaway
Ping → Keycloak removes per-user and per-module licensing in exchange for running your own IdP. Model realms and clients faithfully, prefer LDAP/AD federation over password migration where you can, and if you must import credentials choose between a custom hash provider and a forced reset deliberately. Above all, run both IdPs side by side and move relying parties app by app, identity is the wrong place for a big-bang cutover. Model the removed per-user cost against the engineering time to run Keycloak in HA in the calculator above.