What this integration does
midPoint governs the identity lifecycle for this integration. It decides which people exist as identities, which accounts they should hold, and which group memberships those accounts should carry. Through the Keycloak connector listed in the Evolveum connector catalog, midPoint pushes those accounts and group memberships into Keycloak. The connector is maintained by Openstandia and carries community support status, which changes what your organization can expect from vendor support and how the work is scoped. Before you accept any scope, confirm the connector's documented capabilities and the Keycloak and midPoint versions it has been tested against, because the catalog entry is the authority for what it does and does not handle.
The integration is built on the ConnId connector framework, which midPoint uses for its connectors. Treat that as the supported method and check the connector documentation for the specific operations it implements, such as creating and updating users, managing groups, disabling accounts, and reading existing objects back for reconciliation. Also confirm how it handles Keycloak realms, role mappings, and any attributes your identity model depends on. Any operation missing from the documentation becomes custom work, and that work has to be estimated and owned separately from the standard connector setup.
midPoint is an identity management system. It is not the single sign-on server for your applications, and Evolveum states that midPoint does not implement the server side of OAuth2, OpenID Connect or SAML. Keycloak remains the component that authenticates users and issues the sign-in tokens that applications trust. midPoint's role is to make sure the accounts and group memberships Keycloak relies on are correct and current. Applications that need claims derived from group membership must be configured in Keycloak, and the group data midPoint writes must match what those client configurations expect.
The practical decision is where authoritative data lives and which system is allowed to change it. If an administrator edits a user or group directly in Keycloak, midPoint may later overwrite that change or report a difference, depending on how the connector and synchronization settings are configured. Agree on which side owns each attribute, and test deliberate conflicts during the build. Plan for the failure modes too: a Keycloak outage, a credential or network change that breaks the connector, or a Keycloak upgrade that alters the admin API. Each one should have a named owner, a monitoring check, and a documented recovery step before go-live.
Prerequisites before you start
These prerequisites decide whether midPoint and Keycloak can be connected cleanly. The cards cover the midPoint release and runtime, its database, the Keycloak release and database, the realm that midPoint will manage, the connector build, and the network path with certificates. Settle each item before installation, because a mismatch in any one of them usually appears later as a failed connection.
midPoint release line and Java
Choose the midPoint release line from the releases page before anything else, because it sets your support window and upgrade path. midPoint 4.8 is a long-term support release supported until 17 October 2028, and 4.10 is a feature release supported until 26 November 2027. Match the Java runtime to the release: Java 21 is recommended for 4.10 and older (Java 17 is supported), and Java 25 is recommended for 4.11 and later (Java 21 is supported). Confirm both choices against the system requirements for your exact version.
midPoint repository on a separate server
midPoint uses PostgreSQL as its native repository, and the system requirements recommend a separate database server where possible. Hosting the database apart from the midPoint nodes lets backup, patching and sizing decisions proceed without touching the application tier. Confirm the supported PostgreSQL version for your midPoint release. Ask your database team who owns backups, connection limits and failover, and test a restore before the first production load.
Supported Keycloak release line
Pick a Keycloak release line that your team can keep current, because the project plans four minor releases a year. The current release is 26.8.1, published October 13, 2026, but connector compatibility with that release must be confirmed before you rely on it. Keycloak's supported production databases include PostgreSQL 14 to 18, and the default dev-file database is for development only. Plan Keycloak upgrades separately from midPoint upgrades so each change can be tested alone.
Dedicated Keycloak realm
Create a realm used only for midPoint-managed users and groups, separate from realms that hold administrator accounts or other applications. A dedicated realm limits the scope of the service account and makes it clear which objects midPoint may create, change or remove. Document the realm name, its client settings and the roles granted to the midPoint service account. Review these settings with the owners of the existing Keycloak environment before the connector is configured.
Openstandia connector build match
The Evolveum connector catalog lists a Keycloak connector maintained by Openstandia with community support status. Confirm that the connector build matches both your midPoint version and your Keycloak version before installation, and record the tested combination in your change log. Check with Evolveum whether a community connector falls within your subscription support before you depend on it for production provisioning. Test the connector against a non-production Keycloak realm first.
Network path and trusted certificates
midPoint calls the Keycloak admin API over HTTPS, so its nodes need network access to the Keycloak endpoint and must trust that endpoint's certificate chain. Add your internal certificate authority to the Java trust store used by midPoint, and confirm the certificate names match the hostname in the connector configuration. Open only the required port between the two networks and document the firewall rule. Give the service account the narrowest admin role that the connector needs.
How responsibility splits between midPoint and Keycloak
The split is simple to state and easy to get wrong in practice: midPoint decides who should have an account or group and writes those changes into Keycloak, while Keycloak handles authentication, single sign-on and the tokens that applications receive. midPoint holds the authoritative identity record, applies its role and policy logic, and sends create, update and delete operations to Keycloak through the Keycloak connector. Keycloak then owns the login session, the user's password or other credentials, and the protocol exchange with each relying application.
Evolveum is explicit that midPoint is an identity management system, not an access management or single sign-on server. midPoint does not implement the server side of OpenID Connect, OAuth 2.0 or SAML 2.0, so nothing in midPoint issues tokens to applications. Every application that signs users in through Keycloak needs its own client definition in Keycloak: redirect URIs, allowed scopes, token settings and, for SAML, the signing certificate and assertion attributes. Those definitions are configured in Keycloak, typically under change control in the same way as other Keycloak configuration. A midPoint project does not replace that work, and a plan that assumes midPoint will sign users in will fail at the first application test.
midPoint's own administration interface is a separate decision. The web console can authenticate administrators against an external SSO service, which means Keycloak could sign in midPoint administrators as well as the applications midPoint provisions. That choice affects who can reach the governance console, how administrator sessions expire and how emergency access works if the SSO service is unavailable. Confirm the supported configuration for your midPoint version with Evolveum documentation before you rely on it, and decide separately whether midPoint's console uses Keycloak, a directory account or a local break-glass account.
Because the two systems have different owners, define the boundaries in writing before the build starts. Name the source of truth for each attribute, such as the username, email address and group membership. Decide which Keycloak realm, client and role objects midPoint manages and which ones administrators create by hand, and record that list so an administrator does not edit a managed object and have midPoint overwrite it later. Also agree who approves changes to Keycloak clients, since a client change can grant or remove access without any provisioning event.
Plan for drift and failure at the boundary. If midPoint writes a group membership that Keycloak has not yet applied, or someone changes a user in the Keycloak console, the two records disagree until reconciliation corrects them. Ask your implementation partner how reconciliation runs, how often, and what happens to manual changes. Keep Keycloak's own administrator accounts and recovery procedure independent of midPoint, so that an identity governance outage does not also lock your team out of sign-in.
Configuration sequence
This sequence moves midPoint and a dedicated Keycloak realm from a confirmed version matrix to scheduled, governed provisioning. Each step closes with a check, so the next step starts only after the previous one is proven. The order keeps existing Keycloak accounts unchanged until the team has reviewed what midPoint would do to them.
Confirm versions and connector compatibility
Record the midPoint release, the Java runtime, the PostgreSQL version and the Keycloak release your organization will run. Check each one against the Keycloak connector documentation in the Evolveum catalog. The connector is listed with community support status, so confirm with DeployOpen or your own engineers which connector build works with your exact midPoint and Keycloak versions before build work begins. Done when the version matrix is written down, approved by the platform owner, and any gaps are logged as risks.
Create a dedicated realm and scoped service account
In a Keycloak realm created only for provisioning, define a confidential client for midPoint. Give its service account only the realm-management roles that cover users and groups, as the connector documentation specifies. Keep administrator accounts out of this path and store the client secret in your secrets manager. Done when a client credentials token request succeeds and the account cannot read or change clients, realm settings or any other realm.
Install the connector and create the resource
The platform team installs the Keycloak connector into the midPoint instance, restarts the node, and confirms the connector appears in midPoint's connector list. They then create a resource that points to the Keycloak base URL, the provisioning realm and the service account. They also define the object classes for users and groups. Done when the resource saves without errors and midPoint reports the connector version it loaded.
Test the connection and schema
Run the connection test and the schema discovery from the midPoint interface, then read the logs for the token request and the Keycloak admin API calls. Compare the discovered attributes with the fields your policy depends on, such as username, email, enabled status and group membership. Done when the test returns success, every attribute your policy needs appears in the schema, and any missing attributes are recorded for mapping decisions.
Import and reconcile existing users and groups
Run an import task so midPoint reads existing Keycloak users and groups without changing them. Link those accounts to identities through your correlation rules. Review the results for duplicate matches, accounts with no matching identity, and groups without an owner. Keep automatic changes disabled until the reconciliation report shows no unexpected changes. Done when the team has reviewed the report and documented an owner and a decision for each exception.
Map attributes and group handling, then simulate
Define the inbound and outbound attribute mappings. Decide how group membership is assigned, whether through midPoint roles or direct group assignments. Run the configuration in simulation or against a small test population. Create a test user in midPoint and confirm it appears in Keycloak with the expected attributes and groups. Then disable that user from midPoint and confirm Keycloak reflects the change. Done when the create, change and disable cycle behaves as designed and the simulation shows only expected changes.
Enable provisioning and scheduled reconciliation
Turn on provisioning for the agreed population and schedule reconciliation tasks at an interval your operations team sets. Watch the first scheduled run and compare its report with the earlier test results before widening scope. Confirm that the team has a documented procedure for disabling the resource if unexpected changes appear. Done when the first scheduled reconciliation completes with no unexpected changes and the rollback procedure has been reviewed.
Identity and group mapping
This table compares each midPoint identity attribute and role construct with its Keycloak target, the system of record for that value, and the direction in which it flows. Read it as a starting design for the connector configuration, not a final field list, because attribute names and group handling depend on the connector build you choose. The main takeaway is that username uniqueness and case handling must be decided before the first sync, since they are hard to change once accounts exist.
| Attribute or construct | Keycloak target | System of record | Mapping direction |
|---|---|---|---|
| Identifier (username) | Username (unique per realm, case rules set by realm) | midPoint user object, or HR feed if HR drives identity | midPoint to Keycloak, one way |
| Given name | firstName user field | HR system via midPoint | midPoint to Keycloak, one way |
| Family name | lastName user field | HR system via midPoint | midPoint to Keycloak, one way |
| Email address | email user field | midPoint, confirm against HR | midPoint to Keycloak, one way |
| Lifecycle status (active, disabled, archived) | User enabled flag, confirm how the connector handles disable versus delete | midPoint lifecycle state | midPoint to Keycloak, one way |
| Organizational assignments | Custom user attribute, if the connector exposes it | midPoint org assignments | midPoint to Keycloak, one way; confirm attribute name |
| midPoint roles or groups | Keycloak groups or realm roles, per your design | midPoint role assignments | midPoint to Keycloak, one way; confirm group handling |
| Keycloak-only local accounts or groups | Left unmanaged or excluded by scope | Keycloak admin console | Not synchronized; document the exclusion |
Security settings for this integration
These cards cover the security decisions that determine how midPoint can manage Keycloak users and groups without weakening the realm. Each one sets an identity for the connector, a place where its credential lives, a protected connection, or an accountable administrator. Confirm each setting in your own environment and in the connector documentation before production use.
Least-privilege service account
Create a dedicated service account in the Keycloak realm that midPoint's connector uses, and grant it only the realm-management roles needed to read and manage the users and groups in scope. Keep it out of the admin console, scope it to the single realm where provisioning happens, and document each role against the provisioning action that needs it. Confirm the role list with the connector's documentation before go-live, and test that the account cannot change clients, realm settings or other realms.
Credential in midPoint secret handling
Store the service account's client secret or password in midPoint's secret handling, so configuration refers to the value and the value is never written into the resource definition or exported files. Check how your midPoint version resolves protected values and who can read them, including backups and database dumps. Rotate the credential on a schedule you define, and confirm the rotation procedure updates midPoint and Keycloak in the same change window.
TLS on every connection
Encrypt each hop: midPoint to the Keycloak admin endpoints, the browser to midPoint's user interface, and any call the connector makes to Keycloak. Use certificates issued by your internal certificate authority, and configure midPoint's trust store to validate them, leaving certificate verification enabled. Check the Keycloak hostname and proxy settings so redirects and token endpoints advertise HTTPS URLs, and confirm that traffic between midPoint nodes also uses HTTPS.
Disable or delete on leaver
Decide, before go-live, whether a leaver's Keycloak account is disabled or deleted by default. Disabling keeps the account, its history and its group memberships available for investigation, reinstatement and audit requests, while deletion removes them and can break references in other systems. Record the decision in the governance policy, set it in the midPoint lifecycle configuration, and confirm with legal and records owners how long disabled accounts are retained.
Admin access and MFA
Restrict the Keycloak admin console to named administrators on a management network or through a controlled bastion, and keep those people separate from the service account. Require multi-factor authentication for every administrator and review admin role assignments on a fixed cadence. Apply Keycloak's production configuration guidance to hostnames, proxy headers, database connections and secrets, and confirm the admin endpoints are not reachable from the public internet.
Audit records and drift control
Enable audit logging on both sides: midPoint's records of provisioning actions and Keycloak's admin and user events, forwarded to a log store you control. Enable Keycloak metrics for health and capacity, and alert on failed provisioning runs. Changes made directly in Keycloak can drift from midPoint's record, so set a policy that routes realm changes through midPoint or a reviewed change process, and check for drift on a schedule.
Testing and verification
Before any midPoint and Keycloak provisioning flow reaches production, run a scripted test plan in a non-production Keycloak realm that mirrors the realm's client, role and group settings. The goal is to prove each lifecycle change moves from midPoint to Keycloak as intended, and to find any gap while changes are still cheap to reverse. Write the expected result for every step before the run starts, so that a failure is judged against a written baseline rather than against whatever the output happens to look like on the day. Start with identity lifecycle. From midPoint, create a set of test identities that cover the attributes your provisioning mappings populate, then update one attribute, disable one identity, re-enable it and finally delete a separate test identity. After each step, open the user in the Keycloak admin console and confirm the enabled flag, the username, email and name attributes, and whether the account exists at all. Record the midPoint task or object history reference next to each Keycloak observation so that a mismatch can be traced to a specific midPoint operation.
Next, test group membership in both directions of intent. Add a test identity to one Keycloak group through a midPoint assignment, confirm the membership appears under the user's Groups tab in the admin console, then remove the assignment and confirm the membership is gone. Repeat with a second group to rule out a single-group result. Pay attention to nested or parent groups if your design uses them, because the Keycloak connector's handling of hierarchy is a point to confirm against the connector documentation for your version rather than assume. Run a reconciliation against the Keycloak resource once the scripted changes are complete. Review the report for accounts or groups that midPoint sees differently from Keycloak, and treat every unexpected difference as a finding until it is explained. A clean report after a deliberate, known change set is a stronger signal than a clean report on an untouched realm, so run reconciliation both before and after the test changes. Keep the report output with the test record. Finally, sign into a test application that uses this Keycloak realm for OpenID Connect or SAML sign-in. Confirm that a provisioned account can authenticate, that the account's profile matches what the admin console showed, and that the group claims or role attributes the application expects arrive in the token or assertion. Repeat the sign-in after removing a group to confirm that the claim disappears. This final step is the only one that proves the chain end to end, because midPoint does not issue tokens and Keycloak alone cannot show what a relying party receives. Before sign-off, confirm with your own team and the connector's documentation which operations the Keycloak connector supports in the release you run, and record any unsupported operation as a known limitation rather than a pass.
Common failure points
This table lists the failure points most often seen when midPoint provisions Keycloak users and groups through the community Openstandia connector. Read each row across: the likely cause, how to confirm it, and the direction of the fix. Confirm connector behavior against the Openstandia connector documentation before changing production configuration.
| Failure point | Likely cause | Diagnostic step | Fix direction |
|---|---|---|---|
| TLS connection errors | Keycloak certificate is not trusted by the midPoint Java truststore, or the hostname does not match | Test the Keycloak endpoint from the midPoint host and read the full Java exception chain | Import the internal CA into the truststore midPoint uses and confirm the certificate matches the URL |
| Service account gaps on group operations | The account can read users but lacks the client roles needed to create or change groups | Compare the service account's roles with each failing operation in the connector log | Grant only the group management roles required, then test user and group operations separately |
| Connector and Keycloak version mismatch after upgrade | The connector was built against an admin API that differs from the upgraded Keycloak server | Check the connector release notes against the Keycloak version in the target environment | Pin a connector version tested with your Keycloak release and rehearse the upgrade in a non-production copy |
| Duplicate accounts from username case | The source and Keycloak treat username case differently, so the correlation rule misses an existing account | Search Keycloak for case-only variants of usernames and review the correlation expression | Normalize case in the mapping, confirm Keycloak's username handling in the Openstandia docs, then merge duplicates deliberately |
| Reconciliation overwrites manual Keycloak changes | Attributes or memberships that admins edit directly are marked as managed by midPoint | Review each outbound mapping and check the reconciliation task log for changed values | Mark admin-editable attributes as unmanaged, or move those edits into midPoint so both sides agree |
| Group membership drift with nested groups | Parent and child group relationships are not modeled, so memberships are calculated against the wrong group | Compare midPoint's group assignments with Keycloak's group tree for a sample user | Model nesting explicitly and confirm how the connector handles subgroups in the Openstandia documentation |
| Slow first large import | A full import of users and groups runs in one task with default batch and memory settings | Watch task progress, JVM heap use and database load during the first import run | Run the first import in stages outside peak hours, size heap and database, and confirm batching options in the connector docs |
Questions buyers ask
What drives the cost of midPoint and Keycloak provisioning work?
Scope and complexity drive most of the effort. The main inputs are the number of identities and groups to provision, how many attributes must be mapped from the source of truth into midPoint and then into Keycloak, and how complex those mapping and correlation rules are. Connector validation adds effort because the Keycloak connector is community supported, so your team needs to test create, update, disable and delete flows against your own realm configuration. Keycloak hosting and high availability design add more work, since a clustered design needs a synchronously replicated database. Testing scope, including non-production environments and sign-off, completes the picture. Ask for a written scope that lists each of these inputs so you can compare quotes line by line.
How long does a midPoint and Keycloak provisioning project take?
Duration depends on the scope agreed in writing, so no single timeline applies to every organization. A narrow build that provisions one Keycloak realm from one source of truth, with a small set of groups and standard mappings, is much shorter than a build covering several realms, multiple HR feeds, approval steps and a highly available Keycloak cluster. Schedule risk usually sits outside the code: agreeing which system owns each attribute, getting realm design signed off, and waiting for test accounts and change windows. Ask for a plan that separates environment setup, connector build, mapping and testing, and cutover, with each phase tied to a dependency you can track. The plan should show which of your dependencies sit on the critical path.
Which midPoint and Keycloak costs are one-time and which recur?
The initial build is one-time work: environment setup, connector configuration, mapping design, testing and cutover. Recurring work follows from the platforms themselves. Connector and release upgrades are needed when midPoint or the Keycloak connector changes, so each midPoint release needs a compatibility check before you upgrade. Keycloak patching and upgrades recur because the project plans four minor releases a year, and breaking changes in minor releases are opt-in, which still requires review. Reconciliation review is ongoing: someone must check reports for accounts or groups that have drifted from the source of truth. Ask any provider to split its quote into these categories, and ask whether a support retainer covers upgrades, testing and reconciliation or only incident response.
What must our team provide before a provisioning build starts?
Several inputs are decisions only your organization can make, and they gate the build. Source of truth decisions: name the authoritative HR or directory system for each attribute and who resolves conflicts between systems. Realm design owners: name the people who approve the Keycloak realm, client, role and group structure. Test accounts: provide non-production identities in each target system with the permissions midPoint needs. Change windows: agree when non-production and production changes may happen and who approves them. You should also provide Keycloak administrative access in each environment, hosting details and a named technical contact for connector questions. Missing inputs usually show up as delayed mapping sign-off, so agree owners and dates in the written scope before work begins.
Can our own team build midPoint and Keycloak provisioning internally?
An internal team can build it if it has the skills and time to do so. The work requires Java and midPoint operations experience, working knowledge of Keycloak realms, clients and administration, PostgreSQL administration for midPoint's repository, and enough identity governance knowledge to design mappings and approvals. Check three things honestly: whether anyone has run midPoint in production, whether the team can test the connector against each Keycloak release, and whether it can staff ongoing reconciliation review. Evolveum offers subscriptions and professional services if you want vendor-backed help. DeployOpen can also deliver the build under a fixed written scope. Compare an internal estimate and a partner scope against the same list of deliverables before you decide.
Does Evolveum support the Keycloak connector from Openstandia?
The Evolveum connector catalog lists the Keycloak connector as maintained by Openstandia with community support status, which is a lower tier than supported in the catalog. Evolveum offers Product Support subscriptions for resolving product bugs, with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions that add feature development and roadmap influence. Subscription coverage applies to the product and the connectors Evolveum supports, so confirm in writing with Evolveum whether a community connector falls under any subscription and what that coverage includes. Before you rely on the connector in production, check its catalog status, its compatibility with your midPoint and Keycloak versions, and who will fix defects. Evolveum's support subscriptions page lists no prices, so request a quote for the tier you need.
How does midPoint and Keycloak licensing work?
Both platforms are open source. midPoint's repository is licensed under the European Union Public License (EUPL-1.2), with Apache 2.0 as a secondary license, and Evolveum states that midPoint has no enterprise edition. Keycloak is licensed under Apache 2.0. The software licenses therefore do not change between editions, and your costs come from the build, any subscriptions you buy from Evolveum, and the infrastructure you run. If you choose the Red Hat build of Keycloak, that is Red Hat's supported distribution based on the open source project, so its subscription terms are set by Red Hat. Have legal and procurement review the license texts, and confirm any subscription terms and prices directly with each vendor.
Can midPoint act as our single sign-on server for applications?
No. Evolveum states that midPoint is an identity management system and does not act as an access management or SSO server, and it does not implement the server side of OAuth2, OpenID Connect or SAML. In this design, midPoint decides which accounts, groups and roles each identity should have, then provisions them into Keycloak. Keycloak issues tokens and assertions, handles sign-in, and federates to applications over OpenID Connect, OAuth 2.0 and SAML 2.0. midPoint's own user interface can authenticate against an external SSO service, but that is separate from serving SSO to your applications. Define the boundary explicitly: the source of truth for each attribute, the realms and clients Keycloak exposes, and how application access is granted and removed. Confirm the integration pattern with Evolveum and your Keycloak architect before the design is fixed.
How DeployOpen works on this
DeployOpen treats midPoint and Keycloak user provisioning as two systems with separate jobs: midPoint governs identities and provisions accounts and groups to Keycloak through the community connector, while Keycloak remains the sign-in server. Each engagement starts with a written scope and is delivered inside infrastructure you control.
How we scope
- Written scope names the Keycloak realms, clients and groups midPoint will provision.
- Scope confirms the Keycloak connector's community support status and who answers for it after go-live.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Confirm the midPoint release line and Java version against Evolveum's documentation before installation.
- Configure the Keycloak connector in a lab first, with test accounts, mappings and reconciliation runs.
- Test Keycloak's sign-in path separately, since midPoint does not act as the SSO server.
How we hand over
- Documented runbook covering connector configuration, object mappings, credentials and scheduled reconciliation tasks.
- Keycloak upgrade procedure covering schema migration mode and, where used, Operator approval settings.
- Test evidence and access-review exports that your team can retain for its own audit records.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Plan midPoint upgrades through supported releases, since Evolveum's LTS and feature support windows differ.
- Track Keycloak minor releases, where breaking changes are stated to be opt-in, before scheduling upgrades.
