What a midPoint implementation involves
midPoint is an identity governance and administration (IGA) platform developed by Evolveum. It reads identities from authoritative sources such as an HR system, decides what accounts and access each person should have, provisions and deprovisions those accounts in target systems, and records who approved what. It also runs access certification campaigns, approvals and policy rules such as segregation of duties.
midPoint handles identity lifecycle and governance. Authentication and single sign-on usually stay with an identity provider such as Keycloak or Microsoft Entra ID. The two meet where midPoint maintains the users, groups or directory entries that the identity provider relies on.
Most of the work in a midPoint project is modeling. Each connected system needs attribute mappings, correlation rules and decisions about which source wins for each attribute. Access needs a role model that the business can review. Evolveum's methodology starts with one source and one target and adds systems and governance in short iterations, which is the pattern DeployOpen follows.
A phased delivery plan
Illustrative phases. The order and size of each depend on your sources, targets and audit drivers.
| Phase | Scope | Exit check |
|---|---|---|
| HR source onboarding | Connect the HR system as the authoritative source, define the user schema extensions, correlation and the lifecycle states for joiners, movers and leavers. | Every active employee appears once in midPoint with correct status, organization and manager. |
| First target systems | Connect the directory (Active Directory or LDAP) and one or two business applications, correlate existing accounts and classify orphans. | Reconciliation reports no unexplained accounts, and orphaned accounts have an owner or a disable decision. |
| Lifecycle automation | Automate account creation, changes on transfer and disablement on exit through birthright roles and mappings. | Test joiners, movers and leavers produce the expected accounts in each target within the agreed delay. |
| Governance | Introduce business roles, request approvals, certification campaigns and segregation of duties rules. | A pilot campaign completes and its revocations are provisioned and evidenced. |
Design the identity model
These objects carry most of the design decisions in a midPoint deployment.
Resources and object types
Each connected system is a resource with a connector, a schema and object types such as accounts and groups. Define which attributes are read, which midPoint writes and how activation and passwords are handled.
Correlation and synchronization
Correlation rules match accounts to identities, including weighted rules and fuzzy matching in current releases. Synchronization reactions decide what happens when an account is new, linked, unmatched or deleted, and live sync and reconciliation keep both sides consistent.
Roles, archetypes and organizations
Assignments give a user a role, and inducements pass that role's access down to accounts and groups. Archetypes define kinds of objects, such as employees, contractors or application roles, with their own forms and policies. The organizational structure drives birthright access and approval routing.
Templates, policies and SoD
Object templates compute values such as usernames and email addresses. Policy rules express segregation of duties, approval requirements and other constraints, and marks classify objects such as privileged access or protected accounts.
Configuration, custom code and upgrade cost
midPoint is configured through objects (resources, roles, templates, archetypes, tasks) stored in its repository and kept as XML, JSON or YAML in version control. midPoint Studio, an IntelliJ-based IDE from Evolveum, helps edit, compare and upload these objects. Configuration-only deployments are the easiest to upgrade.
Mappings and conditions can use Groovy, JavaScript or Python expressions. Keep them short, documented and tested, because they run inside midPoint with access to its data. Release 4.10 tightened expression profiles, which restrict what scripts may do, so review scripts against the profiles in your target version.
midPoint uses ConnId connectors. LDAP, Active Directory, CSV and database table connectors cover many systems. Applications with only a REST or SOAP API may need a scripted or custom Java connector, which becomes code you own and test on each upgrade.
Custom GUI pages and Java extensions through an overlay project are possible but carry the highest upgrade cost. Prefer archetype-driven forms and reports first.
Integrations and migration from existing tools
A common pairing is midPoint with Keycloak. midPoint manages users and groups in the directory or in Keycloak, so that a leaver loses access everywhere, while Keycloak handles sign-in and SSO for applications. midPoint can also use Keycloak or another OpenID Connect or SAML provider for logins to its own interface through its flexible authentication modules.
Organizations move to midPoint from homegrown provisioning scripts, Microsoft Identity Manager and older commercial IGA suites. There is no automatic converter. Start by inventorying existing rules, then import accounts from each system and let midPoint correlate them against HR identities. Resolving the orphaned and unmatched accounts this exposes is an early project milestone.
Rebuild the role model with role owners, using role mining to suggest groupings from current access, and retire the old tool system by system.
Testing, rollout and team enablement
midPoint's simulations show what a configuration change would do to users and accounts before it is applied. Use them before switching a resource from read-only to provisioning, before changing a role and before every larger mapping change. Pair them with a test environment loaded from masked copies of source data.
Bring each target system online in stages: read and correlate only, then report differences, then provision with a small pilot group, then enable for everyone. Agree with each system owner what midPoint may change and how to pause provisioning if something goes wrong.
Train the identity team on task results, correlation cases and the Ninja command-line tool, and train role owners and managers on approvals and certification.
Hosting, security and upgrades
What does midPoint need to run?
midPoint is a Java application with its own embedded web server. The 4.8 and 4.10 release notes recommend Java 21 with Java 17 also supported. PostgreSQL with the native repository is the recommended database in 4.8 and the only supported database from 4.10, so older deployments on the generic repository need a database migration as part of an upgrade.
How do we make it highly available?
Run several midPoint nodes against a shared, highly available PostgreSQL database behind a load balancer. Nodes form a cluster and share background tasks such as reconciliation.
What do we back up?
Back up PostgreSQL with its usual tooling, the midPoint home directory with its configuration, and the keystore that holds the keys used to encrypt stored passwords and secrets. A database backup without the matching keystore cannot decrypt protected values. Rehearse a restore into a separate environment.
How should we harden it?
Put the GUI and REST API behind TLS, use SSO with MFA from your identity provider for administrators and keep an emergency login. Limit administrator authorizations and connector service account permissions, apply restrictive expression profiles and review audit records.
How do upgrades work?
Move to the latest maintenance release of your current version first. Each release upgrades to the next one, and an LTS release can upgrade directly to the next LTS. Feature releases go one step at a time, and the 4.10 release notes list a direct upgrade path only from 4.9. Read every intermediate release note, run Ninja to find deprecated items and test with simulations.
Release lines and licensing
From Evolveum's release list and license notices, checked in October 2026. Confirm dates on the release page before planning.
| Release | Type | License | Support ends |
|---|---|---|---|
| 4.8 Curie | Long-term support | Apache 2.0 or EUPL 1.2 (dual) | 17 October 2028 |
| 4.9 Verne | Feature release | Apache 2.0 or EUPL 1.2 (dual) | 18 October 2026 |
| 4.10 Braille | Feature release | EUPL 1.2 or later | 26 November 2027 |
midPoint operating ownership
An IGA platform sits between HR, IT and audit, so ownership has to be explicit on all three sides.
Identity team
- Maintains resources, mappings, roles and templates in version control.
- Resolves correlation cases and failed provisioning operations.
- Plans upgrades and runs simulations before changes.
Platform team
- Runs midPoint nodes, PostgreSQL and the load balancer.
- Backs up the database, midPoint home and keystore.
- Monitors tasks, node health and database growth.
Business owners
- HR owns source data quality and lifecycle dates.
- Role owners approve role content and membership requests.
- Managers complete certification campaigns.
Security and audit
- Define segregation of duties rules and privileged access marks.
- Use certification and audit reports as access review evidence.
- Review exceptions and orphaned accounts.
Scope and handover
Effort depends on the number and type of sources and targets, data quality in HR and existing accounts, how many systems need custom connectors, the depth of the role model, governance requirements such as certification and segregation of duties, and availability targets. Data cleanup and role design usually take longer than connector setup.
DeployOpen runs discovery across HR, IT and audit, designs the identity and role model, builds connectors and mappings, deploys and hardens midPoint in your environment, integrates it with your identity provider, and supports access reviews used as evidence for SOC 2, ISO 27001, DORA or NIS2 readiness. Handover includes the configuration repository, resource and role inventory, correlation and exception procedures, backup and keystore procedure, restore test record and upgrade runbook.
