Keys you hold
Realm signing keys in your HSM over PKCS#11, or in Vault / OpenBao.
Migrate from Keycloak
Your applications already speak OpenID Connect and SAML. HelixIAM imports clients, roles and identity providers from a Keycloak realm export; we plan the rest with you and cut over in phases, with both identity providers running.
Approach
We review your realms, clients, flows, federation and custom extensions, and agree what moves when.
Import clients, roles and identity providers from a realm export into a HelixIAM realm.
Agreed test cases per application: claims, redirects, MFA, logout and admin roles.
Both identity providers run side by side and can federate with each other during the transition.
Applications move one by one, each with a rollback path.
Retire the old realm once every application and user population has moved.
What the importer brings
The importer reads a Keycloak realm export. What it does not import, we plan together in the assessment.
| Item | How it moves |
|---|---|
| OIDC clients | Imported from the realm export |
| Realm roles | Imported from the realm export |
| Identity providers | Imported from the realm export |
| Users and credentials | Not imported by the importer. Planned per population: connect the same LDAP or Active Directory, broker sign-in from Keycloak during the transition, or provision through SCIM 2.0. |
| SAML clients and realm settings | Configured in HelixIAM during the assessment, then covered by the validation plan. |
| Custom extensions | Reviewed in the assessment and mapped to HelixIAM capabilities or integrations. |
Validation
Before any application moves, we agree how you'll know it works.
Why teams move
Realm signing keys in your HSM over PKCS#11, or in Vault / OpenBao.
DigiD, eHerkenning and eIDAS connectors, for use with your own agreements.
Agent identities with owners and delegation, and keyless workload identity.
Send us a short description of your Keycloak landscape and we'll propose an assessment.