Open-source alternative to Okta Identity Governance

Can an open-source tool replace Okta Identity Governance?

If your Okta Identity Governance renewal is forcing a decision, the short answer is that midPoint covers provisioning, role management and access certification campaigns, while access requests and separation of duties usually need custom build work or a confirmed design before you commit. Okta Identity Governance is sold as a subscription on top of an existing Okta tenant, through an account executive, and it bundles access certifications, access requests, entitlement management and separation of duties rules. Before you plan a replacement, map which of those features your auditors and application owners actually use, because that list decides how much of the suite you must rebuild.

midPoint is an *identity governance and administration* platform, not an access management or SSO server. Evolveum states that it does not implement the server side of OAuth2, OpenID Connect or SAML, so login almost always stays with Okta, Keycloak or another identity provider. In practice, midPoint sits beside that provider, reads authoritative sources such as HR data and directories, and pushes accounts and entitlements to target systems through its ConnId connectors, including LDAP, Active Directory, SCIM2 and Microsoft Entra ID. Confirm each target application's connector status in the integration catalog before scoping, since support levels range from supported to experimental.

On licensing, midPoint's repository is under EUPL-1.2 with Apache 2.0 as a secondary license, and Evolveum says there is no enterprise edition, so every feature ships under open source terms. Evolveum funds development through subscriptions, training and professional services. Its Product Support subscriptions cover product bugs with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions add feature development. Those are the recurring costs to weigh against Okta's subscription, along with the one-time build of connectors, certification campaign configuration and the operating effort for your own hosting.

Okta Identity Governance capabilities mapped to midPoint

This table maps each Okta Identity Governance capability to the midPoint feature, connector or custom work that would cover it. Read the middle column for the likely fit and the last column for what your team must confirm in a proof of concept before committing to a design.

Okta capability	midPoint coverage	What to confirm or build
Lifecycle Management (joiner, mover, leaver)	midPoint handles identity lifecycle through its object model, assignments and synchronization from authoritative sources such as HR feeds, CSV or DatabaseTable	Confirm the authoritative source and the attribute mapping for each leaver and mover case in your environment
Workflows (identity automation steps and notifications)	midPoint has its own approval and workflow capabilities for changes, but it does not offer a general no-code automation builder like Okta Workflows	Plan external automation, such as n8n, for notifications and app calls, and test the approval flows against your policies
Access requests	Coverage needs confirmation. midPoint supports approval processes for role and resource assignment, but a self-service request catalog with a requester experience must be verified in the current release	Run a proof of concept for requester UI, approval routing and audit trail, and budget custom development if the catalog is missing
Access certifications	midPoint provides access certification campaigns that review assignments and entitlements, with reviewers, schedules and outcomes recorded	Confirm reviewer workflow, remediation actions and the evidence export format your auditors expect
Entitlement management	midPoint models roles, assignments and resources, and maps entitlements from target systems through connectors	Confirm which entitlements your target systems expose through LDAP, Active Directory, Entra ID or SCIM2 connectors
Resource collections	Resources and role-based grouping are part of midPoint's object model, which approximates Okta resource collections	Map each Okta collection to a midPoint role or resource group and document the naming scheme
Separation of duties rules	midPoint supports policy rules and constraints on assignments, which can express some separation of duties checks	Confirm that your conflict rules can be expressed as midPoint policy constraints and test them with real role combinations
Target connectors (Okta, Entra ID, Active Directory, LDAP)	Documented connectors include LDAP, Active Directory, Microsoft Entra ID (Graph API), CSV, DatabaseTable, ScriptedSQL and SCIM2, per Evolveum's connector documentation	Confirm the Okta connector status in the ConnId catalog, since it ranges from supported to community or experimental, and plan custom work if needed
Cost model	midPoint is open source with no enterprise edition. Paid Evolveum support and platform subscriptions are optional, and the vendor page lists no prices	Ask Evolveum for a support subscription quote and compare it with Okta's per-user licensing, with DeployOpen's fixed-scope implementation quoted separately

Which open-source options fit which governance needs

Okta Identity Governance bundles provisioning, access requests, certifications and entitlement management into one subscription. In open source, these needs are usually split: one platform for provisioning and certification, a second layer for requests and approvals, and an identity provider for authentication. The cards below cover each piece and what to check before you commit.

midPoint for provisioning and roles

midPoint is the primary candidate for the provisioning, role management and certification side of Okta Identity Governance. It is an identity governance and administration platform written in Java, and its connectors cover LDAP, Active Directory, Microsoft Entra ID, SCIM2 and CSV. Check that the target applications you need have a supported connector, because catalog status ranges from supported to community and experimental.

Access request and approval layer

midPoint covers role assignment and certification campaigns, but employee-facing self-service request catalogs and multi-step approvals are a different workload. Plan a complementary tool or a custom workflow for these, and confirm whether its approval logic can call midPoint or the directory of record. Ask how the request history and approver decisions are stored, since auditors will ask for them alongside certification evidence.

Java and PostgreSQL operations

midPoint runs on Linux in a virtual machine or from Docker images, and it uses PostgreSQL as its native repository, ideally on a separate database server. Multi-node deployments need a sticky HTTP load balancer, a shared database and Quartz for task scheduling. Your team carries the JVM upgrades, database backups and cache behavior, and the current recommendation is Java 25 for version 4.11 and later.

Evolveum support subscription tiers

Evolveum sells Product Support subscriptions for resolving product bugs, with an 8x5 next-business-day or 24x7 SLA. Platform Subscriptions add feature development and roadmap influence. The price list is not published on the support page, so ask for both tiers in writing and compare the SLA against your incident response obligations. midPoint itself has no enterprise edition, so the subscription buys support and influence, not extra code.

Authentication from Keycloak or authentik

midPoint is an identity management system, not an SSO server, and it does not implement the server side of OAuth2, OpenID Connect or SAML. Keep authentication in Keycloak or authentik, which federates with LDAP or Active Directory, and let midPoint provision accounts and roles into the directory or applications. Confirm which system is the source of truth for each user attribute before the first certification campaign.

Certification campaign evidence

Access certification campaigns are where Okta Identity Governance and midPoint overlap most directly. Test a pilot campaign on one application, confirm reviewers can see entitlements in context, and export the decisions and remediation records. DeployOpen can prepare these controls and evidence for compliance assessments, but independent auditors decide whether they meet a given framework.

How midPoint runs in your environment

A single midPoint node is the simplest shape. Evolveum's system requirements describe running midPoint on Linux in a virtual machine or from Docker images, with PostgreSQL as the native repository database. The database is best placed on a separate server from the application node, so backups, patching and capacity can be handled independently. A single node suits a pilot, a test environment or a production estate with modest provisioning volume, but it leaves one application process as a single point of failure.

Virtual machine: Install on a supported Linux distribution in a VM you already run, with the database on its own host.
Docker images: Run the published images with a configuration directory mounted from the host, so settings survive image updates.
Separate database server: Keep PostgreSQL off the application node and size it for the connector and task load you expect.
Backups: Back up the database and the midPoint configuration directory together, and test a restore on a second host.
Failure impact: Plan for a maintenance window or outage on the application node, since no second node takes over.

Confirm the exact Linux distributions and Docker image tags you plan to use against the current system requirements page before you build the environment.

Running midPoint alongside Okta or Keycloak

midPoint can sit beside Okta or Keycloak without replacing either one, but the boundary between them must be drawn before anything is connected. The cards below cover the three coexistence patterns, the risks of two sources of truth, and the decisions to settle before go-live.

Okta keeps SSO and MFA

In this pattern Okta remains the login and MFA front door for applications, while midPoint handles account creation, change and removal in target systems through ConnId connectors. midPoint does not act as an SSO server, so it does not replace Okta's sign-in flows. Check which Okta features depend on the directory records midPoint will change, such as group-based app assignments, and confirm how Okta will see accounts that midPoint creates in another system.

Keycloak fed by midPoint

Here Keycloak is the identity provider for applications, and midPoint populates its user store over LDAP or SCIM so that Keycloak sees the accounts and group memberships midPoint manages. This suits organizations that want governance and provisioning in one place and SSO in an open-source stack. Confirm whether Keycloak will hold local copies of attributes, whether it will accept changes made directly in its console, and how group mappings are kept consistent after an identity is moved to a new role.

midPoint UI behind external SSO

midPoint does not implement the server side of OAuth2, OpenID Connect or SAML, but its own administration interface can authenticate against an external SSO service. Administrators and approvers then sign in through the organization's existing identity provider. Decide which accounts keep local midPoint credentials for break-glass access, and test that approvers and certification reviewers can still reach their campaigns if the SSO service is unavailable.

Attribute ownership conflicts

When Okta, Keycloak and midPoint each store a department, job title, manager or group, the same person can have three different values after a change in one system. The risk is that access granted by one source is removed or reviewed against stale data in another, and certification campaigns then certify the wrong state. Write down, attribute by attribute, which system is authoritative and which systems only receive copies.

Group membership and role drift

Group membership is the most common source of drift, because Okta groups, Keycloak roles and midPoint roles can all grant the same application access. A group added by hand in one console may not exist in the governance model, so it is never certified. Decide whether group membership is changed only through midPoint, and set a reconciliation job that compares target system state with midPoint's expected state and reports differences.

Decisions before go-live

Before connecting the systems, settle the authoritative source for each attribute, the owner of each connector and its service account, the change window for reconciliation, and who may make manual changes in each console. Record the decisions as a written operating model and test one joiner, mover and leaver case end to end. Ask the midPoint support provider or your implementation partner to confirm connector support status for each target system before scoping.

Migrating governance data and certification history from Okta

This sequence moves the users, assignments and access model behind Okta Identity Governance into midPoint, then proves the result in a copy before any campaign or access decision depends on it. The output is a tested governance model with a documented parallel-run period and a clear list of what had to be rebuilt by hand.

Inventory Okta groups, assignments and entitlements
The identity team exports users and their app and group assignments from the Okta Admin Console, using the Password Health report CSV or the List Users API with a filter for active users. Resource collections, entitlement definitions and separation of duties rules are documented separately from the Admin Console, so the owners of each access bundle should list them in a spreadsheet with their approvers. Done means every active user, group and app assignment has a row in the inventory, and each resource collection has a named owner. Confirm with Okta what your tenant's reports include, because the exports cover users and assignments, not certification history or workflow settings.
Define roles and policies in midPoint
Architects and governance owners translate the inventory into midPoint roles, organizational units and assignment policies, keeping the business meaning of each Okta group and entitlement. Each role gets an owner, and separation of duties conflicts are written as policy rules in midPoint rather than kept only in a document. Done means every inventory row maps to a role, a rule, or an explicit decision to retire the access, and the owners have signed off the mapping. Expect the mapping to surface groups that were never used or that mixed several purposes.
Connect sources and targets through connectors
The integration team configures ConnId connectors in midPoint for the authoritative source, such as Active Directory or LDAP, and for each target application that currently receives access from Okta. The Microsoft Entra ID, SCIM 2 and CSV connectors are documented options, while any target without a supported connector needs a confirmed integration path before it is scheduled. Done means each source and target shows a successful test connection, and read operations return the account and group data expected from the inventory. Check connector status in the Evolveum integration catalog before committing to a target, because status ranges from supported to community and experimental.
Run reconciliation in a non-production copy
The platform team restores a copy of the midPoint database and the connected test targets into a non-production environment, then runs reconciliation tasks to compare midPoint's view with each target. Discrepancies are sorted into accounts midPoint should own, accounts it should ignore, and accounts that need a human decision, and the role definitions are adjusted to match. Done means the reconciliation report shows no unexplained differences, and each remaining exception has a recorded owner and disposition. Keep the production database untouched during this step, because reconciliation tasks can change target systems when they are not run in simulation mode.
Recreate certification campaigns in midPoint
Governance administrators rebuild the access certification campaigns that Okta ran in Access Governance, using midPoint's campaign definitions for the same reviewers, scopes and recurrence. Open campaigns in Okta should be closed and their open decisions recorded before the cut, because midPoint will not carry an Okta reviewer's pending decision forward. Done means each recurring campaign has a test run in the non-production copy, the reviewers can see the items they are asked to review, and the audit trail shows who decided what. Historical certification records stay with Okta or in your archive, so store a signed export of those records with your compliance evidence.
Rebuild access request and approval workflows
Access request forms, approval chains and notification steps from Okta do not move as configuration, so the workflow owner reproduces each approval path in midPoint or in the request front end your organization selects, and tests every branch with a sample request. Each path is compared with the written access policy, and the owner records who approves what, including any exceptions. Done means every request type in the inventory has a tested approval path, and the approvers confirm the notifications they receive. Confirm with Evolveum which request capabilities are in your midPoint release before designing around them.
Run a parallel period and cut over
Both systems run side by side for a period the governance owner agrees in writing, with midPoint provisioning in a controlled scope and Okta still authoritative for everything else. Reconciliation reports are reviewed on a fixed cadence, and any difference is traced to a role or connector before the next step. Cutover happens only when the parallel reports match and the approvers have used the new request path. Done means the governance owner signs the cutover record, the Okta access governance features are switched off in a documented change, and the final export and certification archive are stored with your evidence.

What the cost of ownership is made of

The main cost difference is structural. Okta Identity Governance is a subscription sold on top of Okta through an Okta account executive or customer success manager, so the governance fee sits alongside the Okta suite you already pay for. The midPoint side carries no license fee, because Evolveum publishes every line of code under open source licenses. What you pay for instead is the infrastructure to run midPoint (virtual machines or Kubernetes, a PostgreSQL database on a separate server, a sticky load balancer for multi-node deployments, and backups), the staff time to operate and upgrade it, any optional Evolveum support or platform subscription, and implementation services. Ask Okta for the governance line items in writing, including what the price is based on, so you can compare the two models line by line.

Split the costs into one-time and recurring items. One-time work covers design of the role model and approval flows, building connectors for systems midPoint does not ship with, and migrating existing entitlements and certification history. Recurring work covers hosting, database and OS patching, midPoint upgrades (the release calendar lists different support end dates for each version, so check which line you run), any Evolveum subscription, and the run staff who review certification campaigns and resolve provisioning errors. The biggest drivers of cost are the number of connected systems, the number of custom connectors, and the complexity of approval workflows. Each new target system adds connector work and test cycles, and each approval step adds configuration and support load.

When you request a quote from an implementation partner, ask for a fixed scope that lists the target systems, the connector for each (supported, community or custom), the workflows to build, the certification campaigns to configure, and the environments to deliver (development, test and production). Ask who maintains the Java runtime and PostgreSQL versions after handover, and whether the proposal assumes a support subscription with Evolveum or a retainer. Confirm which Okta features your governance requirements depend on, since a few may still need the Okta suite to remain in place. Those decisions determine which costs stay recurring and which disappear.

Questions buyers ask before replacing Okta Identity Governance

How much effort and time does a midPoint replacement take?

The effort depends mostly on how many sources, applications and approval paths you need to cover, not on the midPoint software itself, which is free to download and use. Effort rises with the number of HR and directory sources, the number of target applications that need a connector, how many roles you must model, and how many certification campaigns and approval workflows you rebuild. Work usually splits into discovery, role and policy design, connector build and testing, a parallel run against Okta, and cutover. Ask any implementation partner for a written scope with phases and deliverables before work starts, and ask Evolveum or a partner which connectors your target applications need, since the connector catalog ranges from supported to experimental.

Can our own team run a midPoint replacement without outside help?

A team with identity engineering experience and Java operations skills can run midPoint, but a first deployment usually benefits from outside experience with role design and connectors. midPoint is licensed under EUPL-1.2 with Apache 2.0 as a secondary license, and Evolveum states that every line of its code is open source, so there is no license fee to pay. The recurring cost is staff time, infrastructure and, if you want it, a support subscription. Evolveum offers Product Support subscriptions with an 8x5 next-business-day or 24x7 SLA for product bugs, and Platform Subscriptions that add feature development. Ask what your team already runs and what it would have to learn before choosing a self-run or assisted model.

What does the midPoint project need from our people?

A midPoint project needs four groups of people to contribute time, and the gaps usually show up in the first weeks. HR or your authoritative source owners provide employee data and define joiner, mover and leaver events. Application owners confirm which accounts, roles and entitlements exist in each target system and who approves access to them. A database team runs PostgreSQL, which midPoint uses as its native repository, ideally on a separate database server. Platform or operations engineers run the Java application, which is supported on Java 25 for version 4.11 and later and Java 21 for version 4.10 and older, along with load balancing, backups and upgrades. Confirm named owners for each group before scoping.

Does midPoint cover access requests and approvals?

midPoint handles role management, provisioning and access certification campaigns, and it has approval workflows for provisioning changes, but a self-service access request catalog with a shopping-cart style interface is not something to assume from the base product. Okta Identity Governance covers access requests as part of Access Governance, so this is a real functional difference to test. Confirm with Evolveum or your partner whether the request and approval flows you need are available in the current release, or whether they must be built, and whether they integrate with your service desk. Map each Okta request type to a midPoint mechanism during discovery so the gap is visible before any contract is signed.

What happens to our Okta certification history?

Okta certification campaign results and audit trails do not move into midPoint automatically, so plan for how you retain them before you cancel the subscription. Okta documents an export of active users through the Okta Password Health report CSV, the List Users API with a filter, or the community Rockstar browser extension, but a campaign decision history is a different data set and needs its own export or archive plan. Ask Okta what historical reporting you can retrieve before renewal, decide how long your audit or regulatory retention period requires you to keep those records, and agree with your auditors how evidence from the old and new systems will be presented during the transition.

How do we buy support from Evolveum compared with a partner?

Evolveum sells support and platform subscriptions directly, and a partner sells implementation, customization, hardening and ongoing operations, so the two can be bought separately or together. Evolveum's Product Support subscriptions cover product bugs with an 8x5 next-business-day or 24x7 SLA, and its Platform Subscriptions add feature development and roadmap influence. The support page lists no prices, so request a quote from Evolveum for the tier you need. A partner's fee follows from a written scope that covers connectors, roles, certification design and cutover, and it recurs only if you buy a retainer. Ask each party who is accountable for an incident that spans the database, the Java runtime and a connector.

What drives the cost of a midPoint replacement?

Cost has three main components: the people who design and build the deployment, the infrastructure that runs it, and the support or operations you choose to buy. The software license is not a cost line because midPoint has no enterprise edition. One-time costs include discovery, role modeling, connector work and cutover. Recurring costs include servers, PostgreSQL operations, staff time, upgrades and any support or retainer. Costs rise with the number of connectors, the number of certification campaigns and the number of environments you must keep patched. Ask for each quote to separate one-time build work from recurring operations so you can compare it fairly with the Okta Identity Governance subscription, which is sold through an Okta account executive or customer success manager.

How DeployOpen scopes and delivers a governance replacement

A midPoint replacement for Okta Identity Governance touches HR sources, target applications and approval processes, so the work is planned before it is built. The cards below follow the order of a DeployOpen engagement, from the written scope to the support that follows go-live.

Written scope before work starts

Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any build begins. For governance, the scope should list each authoritative source, each target system to be connected, the access request and certification workflows in use, and the separation of duties rules to be carried over from Okta. Ask for the scope to name what is excluded, such as applications that will stay under manual provisioning. A quote follows from that written scope.

Connector inventory and integration

midPoint reaches target systems through the ConnId connector framework, and each connector has its own support status. DeployOpen maps every application in the inventory to a connector, a custom script or a manual step, then builds and tests those integrations in the client's own infrastructure. Confirm the status of each connector in the Evolveum catalog before it is listed as in scope, because community and experimental connectors need their own testing and ownership.

Hardening and backup of the governance stack

midPoint runs on Java and PostgreSQL, and multi-node deployments depend on a sticky load balancer, a shared database and cache invalidation between nodes. Hardening covers the operating system, the database, the TLS configuration, service accounts for connectors and the secrets used to reach target systems. Backup and restore are tested as a procedure, including the repository and the configuration, so that recovery is proven rather than assumed.

Documentation and compliance evidence

DeployOpen prepares the documentation and evidence that an assessor will ask for, such as role definitions, access certification campaign records, change logs and configuration baselines. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so ask early which control objectives the evidence must support and agree the evidence format with the assessor.

Retainers for upgrades and support

midPoint publishes feature releases and long-term support releases on different schedules, so an upgrade plan is part of operations. A retainer can cover ongoing support, the upgrade path between releases and continuous testing of connectors. Separately, Evolveum sells Product Support and Platform Subscriptions for the upstream product, which is a different contract from a DeployOpen retainer. Confirm which parts of the upstream support you need before you agree the retainer scope.