Keycloak vs midPoint: when each one fits and when you need both
If both products are on your shortlist, the first question is whether they solve the same problem. They mostly do not. Keycloak is an access management system: it handles sign-in, issues OpenID Connect and OAuth 2.0 tokens, speaks SAML 2.0, brokers logins to external OpenID Connect or SAML identity providers, and federates users from LDAP or Active Directory. It is licensed under Apache-2.0. midPoint is an identity management system licensed under EUPL-1.2 or later. It provisions accounts into target systems, reconciles what those systems hold against what policy says they should hold, and runs access certification campaigns. Evolveum states that midPoint is neither an authentication server nor an SSO server, so it does not replace Keycloak at the login step. The decision turns on whether your gap is login or lifecycle and governance. If applications need a central sign-in and token service, Keycloak addresses that gap. If the gap is that joiners, movers and leavers are handled by hand across many systems, and no one can show who holds which access, midPoint addresses that gap.
Many organizations run both, with midPoint deciding and maintaining who has an account and which roles it carries, and Keycloak deciding how those people authenticate to applications. Connecting them is an integration project, not a checkbox. Confirm with the vendors and in your own test environment which attributes midPoint writes to the directory or target system that Keycloak reads, how Keycloak federates from that directory (for example through its LDAP or Active Directory federation settings), and whether role or group changes made by midPoint take effect in Keycloak sessions on the schedule you need. Also confirm where the authoritative user record lives, because two systems that both claim to own user attributes will drift apart.
Before you choose, list the systems that need an account, the people who approve access to them, and the evidence an auditor will ask for. If the answer is mostly application sign-in with a small user base, Keycloak alone may be enough, and you can add governance later. If the answer includes certification campaigns, separation-of-duties rules and provisioning into several directories or applications, plan for midPoint from the start and get a written scope from your implementation partner that names each connector and each target system. Ask any vendor or partner to show the integration working on your own data before you commit.
Which platform fits which scenario
This table maps common Keycloak and midPoint scenarios to the platform that fits better and the condition that decides it. Read each row as a starting point: many organizations need both, and the deciding factor is usually whether the problem is sign-in or account lifecycle and review.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| One web application needs single sign-on | Keycloak | Keycloak brokers OpenID Connect and SAML logins for the application; midPoint is not an SSO server and would add no sign-in capability here. |
| Workforce needs joiner, mover and leaver accounts across many target systems | midPoint | Choose midPoint when accounts must be created, changed and removed in several target systems from authoritative HR or directory data. Keycloak does not provision accounts into external targets in this role. |
| Auditor requires periodic access reviews | midPoint | midPoint runs access certification against entitlements it manages. Confirm which target systems and entitlement types your reviews must cover before assuming coverage. |
| Mixed estate with Active Directory | Both, with clear roles | Keycloak can federate users from LDAP or Active Directory for sign-in, while midPoint can provision accounts into directories. Confirm which system is the source of truth for each attribute before connecting them. |
| B2B product where customers manage their own users | Keycloak | Keycloak suits customer sign-in and federation into the product. Confirm the multi-tenant model you need, since Keycloak realms and per-customer isolation are a separate design decision from midPoint's governance focus. |
| Small internal tool with a handful of users and no review requirement | Keycloak | Without target-system provisioning or certification requirements, governance tooling adds operating cost without matching need. |
| Regulated organization needing both sign-in control and evidence of who has which access | Both | Keycloak issues the authentication; midPoint maintains the access record and review evidence. Plan the integration so that Keycloak roles or groups reflect what midPoint has approved. |
How Keycloak and midPoint are built and deployed
Keycloak and midPoint sit in different parts of the identity stack and run very differently day to day. The cards below cover what each one runs as, what it depends on, and what that means for the team that will operate it.
Keycloak runs as a Java server
Keycloak is a Java server that handles sign-in, token issuance and federation for applications. It supports OpenID Connect, OAuth 2.0 and SAML 2.0, brokers logins to external identity providers, and federates users from LDAP or Active Directory. Check that your team can operate a Java service with its own upgrade path, clustering and certificate handling before you commit to it.
Relational database required in production
Keycloak needs a relational database in production. The supported options include PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Amazon Aurora PostgreSQL. The default dev-file database is not suitable for production. Confirm which engine your database team already backs up, patches and monitors, because that engine becomes part of the identity service's availability plan.
Operator deployment on Kubernetes or OpenShift
On Kubernetes or OpenShift, the Keycloak Operator can be installed through the Operator Lifecycle Manager, which Keycloak recommends, or with kubectl. Using the Operator means your cluster team owns the lifecycle of the Keycloak custom resources. Ask who will apply Operator upgrades, how database credentials are injected, and whether your platform already runs OLM.
midPoint provisions and governs, it does not log in
midPoint is a provisioning and governance system. It connects to authoritative sources and target systems, creates and changes accounts, reconciles what each system holds against policy, and drives access certification. It does not authenticate users or issue single sign-on tokens. Evolveum states that midPoint provisions accounts to access management systems, so a product such as Keycloak usually sits beside it rather than being replaced by it.
Connectors and reconciliation drive midPoint work
Most of midPoint's operating effort goes into the connectors to each target system, the mappings that turn source attributes into account attributes, and the reconciliation runs that catch drift. Each new application or directory is a new connector and mapping set to build, test and maintain. Ask who owns the connector backlog and who reviews reconciliation results after go-live.
Staffing differs for each system
Keycloak staffing centers on the authentication service, its database and its integrations with applications. midPoint staffing centers on identity data modeling, policy and connector work, and it needs people who understand both HR sources and target system schemas. Expect to need both skill sets if you run the two together. Confirm with the vendor and your implementation partner which roles each system needs in your environment before scoping the work.
Capability comparison: sign-in, provisioning and governance
This table compares how Keycloak and midPoint divide the identity lifecycle, from sign-in to account provisioning and access review. Read each row as a question of which product does that job in your architecture, and check the items marked for vendor confirmation before you commit. The main takeaway is that the two tools are usually complementary, and only Keycloak handles sign-in for applications.
| Capability | Keycloak | midPoint |
|---|---|---|
| Primary purpose | Access management: sign-in, tokens and single sign-on for applications | Identity management: provisions accounts to access management systems and other targets |
| Protocols | OpenID Connect, OAuth 2.0 and SAML 2.0 | Not an authentication or SSO protocol server. Confirm connector coverage for each target system. |
| Login and SSO | Provides login and SSO, and brokers logins to external OpenID Connect or SAML identity providers | Does not authenticate users or provide SSO. Applications still sign in through an access management system such as Keycloak. |
| User federation | Federates users from LDAP or Active Directory | Reads account data from connected resources. Confirm which directories and sources your version reads natively. |
| Account provisioning to target systems | Manages accounts inside Keycloak. Pushing accounts into other systems depends on integrations you build or add, so confirm with the Keycloak project. | Core purpose: provisions accounts to target systems. Confirm the connectors you need for each target before scoping. |
| Reconciliation | Keeps federated LDAP or AD users in its own store. Not positioned as a cross-system reconciliation engine. | Reconciles account state between midPoint and connected systems. Confirm reconciliation behavior per connector. |
| Access certification | Not a documented governance function. Confirm in the Keycloak documentation before assuming any built-in review workflow. | Runs access certification for reviewing who holds which access. Confirm the review workflow meets your control evidence needs. |
| Database requirements | Relational database required in production: PostgreSQL 14 to 18, MariaDB, MySQL, SQL Server, Oracle or Aurora PostgreSQL | Confirm supported database engines and versions with Evolveum before sizing the deployment. |
| License and support model | Apache-2.0, current release 26.8.1 (October 13, 2026). Confirm any commercial support options with vendors. | EUPL-1.2 or later with no Enterprise Edition. Evolveum sells support subscriptions. Current maintenance release is 4.10.5. |
What each license allows and what is paid for
Keycloak is licensed under Apache-2.0, and the current release is Keycloak 26.8.1, released on October 13, 2026. The license lets you run, modify and redistribute the software without a per-user or per-server license fee from the project. The cost of running Keycloak in production is therefore mostly the infrastructure, the database, the people who operate it and any external support you buy. The points below describe what that means in practice.
- Apache-2.0 terms: The license permits commercial use, modification and redistribution, subject to its notice and attribution conditions. Have your legal team confirm how those conditions apply to any custom themes, extensions or patches you ship.
- No license tier for features: The features discussed on the project pages are part of the same codebase. Keycloak does not split core sign-in, federation or administration into paid editions that you must buy to run in production.
- Recurring costs sit elsewhere: Database licensing, hosting, backups, upgrades and staff time recur. If you use a commercial database such as Oracle Database or Microsoft SQL Server, its license terms apply separately from Keycloak's.
- Support is optional: Support and maintenance can come from your own team, from DeployOpen under a written scope, or from a third party. Ask any provider which Keycloak versions they cover and for how long.
- Upgrade planning: Each new release, including 26.8.1, requires a planned upgrade and regression testing in your environment. Budget that effort even though the software itself costs nothing to license.
Before you commit, confirm the license terms against the current LICENSE file and the release notes for the version you plan to deploy.
midPoint is licensed under EUPL-1.2 or later. Evolveum states that there is no Enterprise Edition: every line of code is open source, so the feature set you download is the same one that Evolveum supports. Evolveum sells subscriptions for support, which is the commercial relationship you enter when you need vendor-backed help. Current lines include 4.10.5 as the maintenance release, supported until November 26, 2027, 4.8 as the long-term support line supported until October 17, 2028, and 4.11, which is planned for October 21, 2026.
- EUPL-1.2 or later: The license is a copyleft license. Review its obligations with counsel before you modify midPoint and distribute the modified product, or offer it as a service to others.
- No paid feature edition: Evolveum does not gate functionality behind an Enterprise Edition. Your purchasing decision is about support and service levels, not about unlocking features.
- Subscription covers support: Paying Evolveum buys support and access to vendor help, not a different license for the software. Ask what the subscription includes, response expectations and which releases are covered.
- Choose the line deliberately: 4.8 LTS has the longest stated support window in the list above. 4.10.5 is the maintenance line, and 4.11 is the planned next line. Pick the line that matches your change tolerance and audit cycle.
- Recurring and one-time costs: Implementation, connector work, testing and migrations are typically one-time. Subscriptions, hosting and staff time recur.
Check the current release page and LICENSE file before you finalize a line, because support windows and planned dates can change.
Paying for software and paying for support are different purchases, and the two projects differ in how they are structured. Under Apache-2.0, Keycloak has no license fee to pay. Under EUPL-1.2 or later, midPoint also has no license fee, and Evolveum sells subscriptions for support. In both cases the real budget is the work of running the platform: deployment, integration, testing, operations and audit evidence. Keep those costs visible when comparing the two.
- Software license: This is the right to use, modify and distribute the code. For both projects it is not the main cost driver in production.
- Vendor support: This is a service contract. It buys response, troubleshooting and access to vendor expertise for a defined period.
- Implementation services: These are one-time, scoped work such as design, configuration, integration and hardening. DeployOpen provides this work under written, fixed scope.
- Ongoing operations: Patching, upgrades, backups, monitoring and on-call coverage recur for the life of the system.
- Quote requests: Ask every provider what is in and out of scope, which versions are covered, how long support lasts and what happens at the next upgrade.
Before you approve a budget, reconcile these lines against your own staffing model and your support requirements.
How Keycloak and midPoint connect in one identity stack
In a combined stack, midPoint holds the authoritative lifecycle data (joiners, movers and leavers, roles and entitlements) and provisions accounts into the systems that users actually sign in to. Keycloak sits in front of those applications as the access management layer, handling OpenID Connect, OAuth 2.0 and SAML 2.0 logins and brokering to external identity providers. The two products do different jobs, and midPoint does not replace Keycloak's sign-in role. Evolveum states that midPoint is an identity management system, not an access management system, so it is neither an authentication server nor an SSO server.
There are two common paths for identities to reach Keycloak. In the first, midPoint writes accounts into a directory such as LDAP or Active Directory, and Keycloak federates users from that directory through its user federation settings, so Keycloak reads identities rather than storing the master copy. In the second, midPoint provisions accounts directly into applications or into a store that Keycloak uses, and Keycloak's own user records are kept in step by the integration design. Ask the team which path fits your estate, who owns each attribute, and where a disabled account must be blocked so that a leaver loses sign-in at the right point.
The integration path must be designed and confirmed in your own environment before any build starts. Check which directory you use, how midPoint's resource connectors map attributes, whether group and role membership reaches Keycloak in the form your applications expect, and how deprovisioning propagates when a session is still active. Confirm each of these against the current documentation for both products and your own test results. A scoped design document that names the source of truth for each attribute is the most useful artifact to agree on before a quote for the integration is finalized.
What drives the running cost of each
Running cost for Keycloak and midPoint comes from different places: one is an access platform that sits in the login path, the other is a governance system that depends on the accuracy of the systems it provisions to. The cards below separate one-time build work from recurring operation, upgrades, support and certification cycles, so you can ask each vendor and each implementation partner for the right line items.
Database and hosting
Keycloak needs a relational database in production, and its supported list includes PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Amazon Aurora PostgreSQL. Your database licensing, backup retention and high-availability design therefore carry a recurring cost. midPoint also needs a database for its repository. Ask which engine your organization already licenses and operates, and whether the cost of a managed service is included in the quote.
Staff skills for each platform
Operating Keycloak is mostly an identity and application security skill: realms, clients, protocol mappers and federation settings. Designing midPoint is closer to data and process work: object models, resource mappings, roles and policies. These are different people, and a team strong in one area often needs to hire or contract for the other. Budget for training and for at least one person who can own each platform after the project closes.
Vendor subscriptions and support
Keycloak is Apache-2.0 licensed, so the software itself carries no license fee, but production support is bought from a third party or delivered internally. midPoint has no Enterprise Edition: every line of code is open source, and Evolveum sells subscriptions for support. Compare what each subscription covers, response commitments and whether support is per installation, per user or per seat before assuming either option is free to run.
Upgrade effort on release lines
Keycloak moves quickly, with 26.8.1 as the current release, so plan for a regular upgrade rhythm and test custom providers and themes on each one. midPoint publishes a long-term support line and a maintenance release with separate end-of-support dates. Choosing the release line you will stay on determines how often you must upgrade and how much regression testing each upgrade requires. Ask each vendor what its support window is for the line you select.
Connectors and integrations
Keycloak costs grow with each application that needs a protocol configuration, a claim mapping or a custom authenticator. midPoint costs grow with each target system it provisions to, because every resource needs a connector, a mapping and testing against real accounts. Connector development or customization is often the largest recurring line item in governance projects. Ask whether each target system has a maintained connector, who maintains custom ones and how they are tested after upgrades.
One-time design versus recurring work
One-time work includes the identity design, federation setup, role modeling and initial integrations for both platforms. Recurring work includes operations, patching, upgrades, access review cycles and evidence preparation for compliance assessments. Be wary of quotes that price the build but omit the recurring operations and certification cycles, since those are the costs that continue for the life of the system. Ask the implementation partner to split the quote into one-time and recurring items.
Adding midPoint to an existing Keycloak deployment, or the reverse
The sequence separates who signs users in from who decides which accounts exist and what they may hold, so each platform can be added or changed without rebuilding the other.
Inventory identities, sources and target systems
The identity owner and the platform team list every authoritative source of people and accounts, such as HR records, directories, and the applications Keycloak already serves. They also record which applications hold local users, which use shared groups, and which accounts are service or shared accounts. The step is done when each source has a named owner and each application is marked as an authentication client, a provisioning target, or both. Ask the midPoint and Keycloak maintainers to confirm which connectors and client protocols your target systems require, since support depends on the version you deploy.
Define roles, entitlements and ownership
Working with application owners and the business, the team turns today's group memberships and ad hoc grants into a defined set of roles and entitlements, each with an owner and a purpose. Many organizations find that Keycloak realm roles or client roles map to some of these, but the policy about who may request or approve them lives outside sign-in. The step is complete when the role catalog is reviewed and signed off, and each entitlement can be traced to a source system and an approver. Expect this to be the most decision-heavy part of the work, and do not start connector configuration until the catalog is agreed.
Connect midPoint to target systems in read mode first
The integration team connects midPoint to the authoritative sources and to the target systems in read-only or reconciliation-only mode, so it can compare what exists with what the policy says should exist. Mappings, correlation rules and the handling of accounts that match nobody are tested here, before any account is created or removed. Done means reconciliation reports show the differences are understood and explained, with no unexpected deletions queued. Keycloak remains the sign-in path throughout, so users are not affected by this phase.
Keep Keycloak as the sign-in and federation layer
Keycloak continues to handle OpenID Connect and SAML sign-in, brokering to external identity providers, and LDAP or Active Directory federation where those are in use. The team checks that the accounts midPoint manages are the same identities Keycloak authenticates, by confirming the shared identifier and the attribute used for matching. The step is complete when a test sign-in succeeds for a provisioned account and for an unchanged account, and the client configuration in Keycloak has not been altered by the midPoint work. Confirm with the Keycloak documentation how your chosen federation mode handles accounts that midPoint creates or disables.
Enable provisioning with a rollback path
After reconciliation results are accepted, the team switches selected mappings from report-only to active provisioning, starting with a limited group of users or one target system. Each change is logged, and the team confirms that disabling an account in midPoint produces the expected result in Keycloak and in connected applications. The step produces a tested rollback procedure and evidence that a sample of joiner, mover and leaver events behaved as the policy states. Expand the scope only after this evidence is reviewed.
Add access certification campaigns
Once provisioning is stable, the governance team defines certification campaigns in midPoint for the roles and entitlements that matter most, with named reviewers for each. Reviewers confirm or revoke access, and midPoint records the decisions and applies revocations through provisioning. The step is done when a pilot campaign has completed, its decisions have been applied or deliberately overridden, and the records are retained in a form your auditors can request. Certification prepares the evidence and controls; it does not replace an independent assessment.
Document what transfers and what is rebuilt
The team writes a short record of what carried over and what was rebuilt. User records, group structures and protocol clients in Keycloak generally remain in place, because midPoint is added alongside them. Provisioning logic, mappings, correlation rules and certification campaigns are new work in midPoint. In the reverse case, where midPoint is already in place and Keycloak is added, the sign-in configuration is new while identity records and entitlement definitions carry over. The step is complete when the owners sign the record and it is kept with the runbooks.
Where implementation projects run long
Keycloak projects usually run long on realm design, client configuration and federation mapping, not on installation. Before work starts, the client should decide how many realms the estate needs, which users live in which realm, and which applications become OpenID Connect or SAML clients. Each client needs its redirect URIs, token lifetimes and scopes agreed with the application owner, and each LDAP or Active Directory federation needs attribute mappings agreed with the directory owner, including how group membership becomes Keycloak roles. Inputs to gather early include the application inventory, the directory schema and service account details, and the external identity providers to broker. Confirm the production database choice from the Keycloak database guide (PostgreSQL 14 to 18 is listed) and the hosting model for the Keycloak Operator, since both shape the install before any realm exists.
midPoint projects usually run long on data quality, role modeling and connector work. Evolveum describes midPoint as an identity management system that provisions accounts to target systems, so its value depends on authoritative sources that are accurate enough to drive those accounts. Before work starts, the client should name an owner for the HR or directory source of truth, agree which attributes define a person, and decide how roles are modeled, including which business roles map to which entitlements in each target system. Each target system needs a connector, a reconciliation rule and an owner who approves account changes. The inputs to gather include the source system extracts, the list of target systems with their administrators, and the access catalog. Ask the vendor or the implementation partner to confirm which connectors are needed and whether each one is included in the chosen midPoint release line, since the midPoint release page lists the supported versions.
For both products, the schedule risk is decisions without owners. Each open question on realm strategy, role catalog, certification scope or approval authority should have a named person and a date before work begins. Fixed-scope engagements are agreed in writing before work starts, so the scope document should list these owners, the inputs the client supplies, and the acceptance criteria for each deliverable. Changes after signing usually cost time, so a quote should show what is included, what the client must provide, and what is excluded. Illustrative example: if the directory team has not agreed the attribute mapping, the federation work stops until they do, and the project plan should show that dependency rather than assume it away.
Questions buyers ask before choosing Keycloak or midPoint
Can midPoint replace Keycloak, or Keycloak replace midPoint?
No, in most architectures the two do different jobs and are not interchangeable. Evolveum states that midPoint is an identity management system, not an access management system, so it is neither an authentication server nor an SSO server. Keycloak handles sign-in, OpenID Connect, OAuth 2.0 and SAML 2.0 federation, and brokering to external identity providers. midPoint provisions accounts and group memberships into target systems, reconciles them against authoritative sources and runs access certification campaigns. Keycloak can federate users from LDAP or Active Directory, but it does not run lifecycle workflows or certification reviews across a wide estate of applications. Teams that need both usually use midPoint to decide and provision who holds an account, and Keycloak to decide how those people sign in. Confirm the target systems you need to provision before assuming either product covers them.
Do we need midPoint to pass an access audit?
Not necessarily, but you need evidence that someone reviews who has access and removes what is no longer justified. Access reviews and joiner, mover and leaver processes are the controls auditors ask about most often, and midPoint is built to automate those steps across systems. Keycloak can show sign-in events and realm configuration, but it does not run certification campaigns against every downstream application. If your scope is small, with a handful of applications managed through Keycloak groups and a documented manual review, a governance product may be more than you need. Ask your auditor which controls and evidence they expect for your framework, and map those to the systems that will produce them. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit report or attestation.
What does the work need from our own team?
Your team needs ownership of the authoritative sources, the access policy and the target systems. Keycloak work requires people who can manage realms, clients, identity brokering, database connections and upgrades, and who understand OpenID Connect and SAML trust configuration. midPoint work needs people who can define the identity model, write mappings and roles, connect resource adapters and decide who approves access. Both platforms are open source, so your team carries the operational duty for whichever you run, including patching and backups. The skills gap is usually larger for midPoint than for Keycloak, because policy design takes time and business input. Before a project starts, name an accountable owner for each source system and each approval step.
Can our own engineers implement this without an outside partner?
A capable platform team can implement Keycloak with its own staff, especially for a single application or a small set of federated logins. midPoint is harder to run without outside help the first time, because its value depends on a well-designed identity model, reconciliation rules and certification workflows. Check three things honestly: whether you have people with time to learn the product, whether you can test against real target systems in a non-production environment, and whether you have a rollback plan for account changes that touch production. DeployOpen plans, implements, integrates and hardens self-hosted open-source platforms inside your own infrastructure, usually under a fixed scope agreed in writing before work starts.
What drives the cost and effort of a Keycloak or midPoint project?
Both platforms are open source, so license fees are not the main cost driver. The cost comes from people, infrastructure and integration. For Keycloak, the drivers are the number of clients and realms, the federation sources, the production database and high availability design, and the Kubernetes or virtual machine operations you need. For midPoint, the drivers are the number of source and target systems, how many roles and policies you define, the quality of your source data, and the approval and certification workflows. One-time costs include design, integration and migration. Recurring costs include operations, upgrades, testing and any subscription support you choose. Ask any implementation partner for a quote that lists each system, each integration and each workflow, and separates build work from ongoing operations.
How long does a Keycloak or midPoint project take?
Duration depends on scope rather than on the product name, and no fixed figure applies across environments. A Keycloak project usually moves faster when it covers a limited set of applications and a single identity source. A midPoint project usually takes longer because it needs agreed identity data, role design, connector work and certification rules before anything goes live. Integration with existing directories, such as Active Directory, can add time for access and testing. Ask for a timeline stated against a written scope, with the systems, environments and approval steps listed. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the timeline should follow from that document.
Do we need a support subscription for midPoint or Keycloak?
Support subscriptions are a choice, not a licensing requirement, for both products that you run in production. midPoint is fully open source under EUPL-1.2 or later, and Evolveum states there is no Enterprise Edition, but it sells subscriptions for support. Keycloak is licensed under Apache-2.0, and you can run it without a vendor subscription. The question is whether your team can absorb security patches, upgrades and incident response without a vendor. Compare vendor support with an ongoing retainer from an implementation partner, and confirm what each covers, including response expectations and supported release lines. Check the midPoint release page for supported lines before choosing a version.
How DeployOpen helps choose, implement or migrate
Keycloak and midPoint solve different problems, and many organizations end up running both. DeployOpen is a Chainscore Labs company that plans, implements and supports self-hosted open-source platforms inside your own infrastructure, and it does not favor either platform. The cards below cover the decisions and checks that come before any build.
Scope the sign-in and governance split
Start by separating who signs in from who should hold which account. Keycloak handles login, federation and tokens for applications, while midPoint provisions accounts, reconciles them against connected systems and runs access certification. We map each application to one or both roles so that neither platform is asked to do work it was not built for. The output is a written scope that names the systems of record and the owner of each attribute.
Design the Keycloak deployment
Keycloak needs a relational database in production, so the database choice, backups and high availability are part of the design from day one. We plan the database engine, the Operator or container deployment, and how federation from LDAP or Active Directory is configured. Ask any partner to confirm which database versions and Keycloak release line they will support before work starts.
Connect midPoint to target systems
midPoint earns its place when accounts must be created, changed and removed across several systems on the basis of an authoritative source. We define resources, mappings and reconciliation rules, then test how the system handles conflicting or orphaned accounts. Ask for a written list of connectors and the systems each one touches, since integration effort usually depends more on those target systems than on midPoint itself.
Set up access certification
Access certification asks managers and owners to confirm that each person still needs each entitlement. We prepare the review campaigns, reviewer assignments and the evidence trail that shows decisions were made and applied. DeployOpen prepares these controls and records for your compliance assessment, but the audit report itself comes from an independent auditor or certification body.
Harden and test both platforms
Identity systems sit on the critical path for every application they protect. DeployOpen runs security testing against applications, APIs and infrastructure, and reviews how Keycloak and midPoint handle their credentials, connectors and administrative access. Confirm in writing which environments are tested, how findings are reported, and whether retesting is included.
Fixed scope and ongoing support
Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers, which matters because both platforms receive regular releases. DeployOpen does not publish a price list, so a quote follows from the written scope you approve.
