MidPoint: an identity governance and administration platform in Java

What MidPoint is for

MidPoint is described as a full Identity Governance and Administration platform, used by organisations around the world to deal with Identity Provisioning, Identity Governance and Compliance, and also Access Management.

There is a sentence in the README that frames the whole product, and it is worth reading closely. As for the identity being a security perimeter, midPoint keeps safe both organization's internal network and external resources.

That is the claim that distinguishes an identity platform from a directory server. A directory stores identities and authenticates them. An identity governance platform is about the question of authorisation over time: who should have access to what, who approved it, when does it expire, and can you show an auditor the trail. MidPoint's feature list is a catalogue of the activities involved in answering that.

The headline features are six. Identity Governance. Security auditing and reporting. Organizational structure management. Credential Management. Request approval. And Entitlement Management.

The framing of access as a governance problem rather than a permissions problem runs through the rest of the list. There is user provisioning and deprovisioning, so accounts come and go. There is an administration GUI. There is an identity repository implementation backed by SQL, so MidPoint is its own source of truth for identities rather than depending on a directory. There is custom schema extensibility, which matters because a real organisation has attributes no vendor anticipated.

The identity synchronisation side covers liveSync, reconciliation, discovery and import, and the mapping language supports expressions in Groovy, JavaScript and Python. Offering three scripting languages in the same product is a pragmatic choice, since the people writing provisioning mappings are often not the same people who administer the platform, and the team that knows Groovy may not be the team that knows Python.

The project is written in Java, the homepage is midpoint.evolveum.com, and the last push was on 2026-10-20. The README header names the branch as the MidPoint 4.11.0 Development Branch, and there are no GitHub releases, so the version is tracked in the repository rather than in tags.

The features that only a governance platform would have

Most of the feature list is things any identity system might claim. A few are not, and they are the ones that tell you what MidPoint actually does.

Advanced RBAC support with temporal constraints is the first. Access that is granted for a period and then expires on its own is a requirement in any regulated environment and is not something you bolt onto a directory afterwards. It also implies that the platform tracks when access was granted and by what authority, which is the seed of the audit trail.

Entitlements are the second. An entitlement is a describable unit of access rather than a raw permission on a resource, and having them as first-class objects is what makes a catalog of what a role can grant possible. Request approval and Identity management process automation are listed separately, and the workflow and notifications support is what implements them.

Archetypes are the third, and they are a modelling concept rather than a feature most people recognise. An archetype is a pattern that describes a kind of object and the properties it has, which is how MidPoint extends its own schema without every deployment writing code. Combined with custom schema extensibility, it is the mechanism by which the product adapts to an organisation's data model rather than the other way around.

Provisioning consistency and error handling is the fourth and the most operationally important. A provisioning system that creates accounts in fifteen systems will, sooner or later, succeed in nine of them and fail in six. Deciding what happens in that case, whether to retry, whether to roll back, and how to surface it, is a hard problem that a feature list can hide but a governance platform has to answer.

Then the ones that round it out. Password policies, password reset, credential management. Data protection, marked experimental, which is the wording a project uses for something it does not yet want to promise. Reporting and notifications, which are how the results reach the people who need them.

The interfaces are listed last and they are broad: local Java APIs, a remote web service interface over SOAP, and a REST API. Three of them, with SOAP for the integrations that predate REST and REST for the ones that do not.

Connectors, and the repository layout

The repository layout shows how large this is, and the directory names are the most informative part of it.

There is a `model/` directory, which is where the object model lives, and the modelling work described in the feature list is implemented there. There is a `gui/` directory for the administration interface, `provisioning/` for the provisioning engine, and `infra/` for the infrastructure layer that the rest sits on. There is `docs/` and `release-notes.adoc` and `milestone-notes.adoc`, so the documentation and the release history are part of the repository. `dist/` and `install-dist.adoc` are for the distribution, `repo/` for the artifact repository configuration, `testing/` for the test suites, and `tools/` for developer tooling.

The `icf-connectors/` directory is the one to look at first for a sense of what MidPoint can connect to. ICF is the Identity Connector Framework, the specification for connecting an identity management system to a target, and having a directory of them means the connector set is a real and extensible surface rather than a fixed list. The feature list confirms the support for ConnId connectors, the open source identity connector framework.

Two directories at the root are worth a second look. `config/` holds configuration, and `custom/` is presumably where deployment-specific customisation goes, which for an identity platform is a distinction that matters: the stock product is the same for everyone, and everything an organisation adds for itself is kept separate.

The `samples/` directory has a README, so the samples are the entry point for seeing what a working MidPoint setup looks like.

Two files at the root are the project's way of telling you what state it is in. `NEWS` and `RELEASE-NOTES` are the release notes, and `INSTALL` and `INSTALL-dist` are the installation instructions for the source build and for the distribution respectively. Having both means there are two ways to install the thing and they are documented separately, which is a sign of a product that is both developed as source and shipped as a packaged distribution.

There is also a `publiccode.yml`, which is the metadata file for the European public code hosting platform, and `NOTICE`, which is the attribution file required by the licence.

Two licences, and what they cover

The licensing is unusual and worth reading precisely, because the two licences cover different things and one of them has terms that affect what you can do with the documentation.

This project is licensed under the European Union Public License. The documentation is licensed under the terms of the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International license. The LICENSE file has the details, and the repository root carries `LICENSE`, `LICENSE.EUPL` and `LICENSE.CC` as separate files, one per licence.

The EUPL is the European Union Public Licence, and it is the licence the European Commission uses for software it wants to remain reusable. GitHub's licence detector cannot classify it, which is simply because GitHub's licence detector does not have a category for it.

The documentation licence is where the sharp edges are. Attribution-NonCommercial-NoDerivatives is three restrictions in one: you must credit the source, you cannot use it commercially, and you cannot publish derivative works. NoDerivatives in particular is stricter than most people expect, because it covers adaptations, not just redistribution. Translating the documentation, or producing a condensed guide from it, falls inside what that clause restricts.

So the practical split is this. The source code carries a EUPL, which is a copyleft-style licence with a reciprocity requirement. The documentation, which is the writing most people actually want to quote and republish, is licensed with terms that forbid commercial use and forbid derivatives. A consultancy preparing training material from the MidPoint documentation, or a vendor writing a translated guide, has to think about that clause.

The other licensing detail in the repository is `publiccode.yml`, the metadata file for the European public code platform. That file is where a deployment declares who runs the software and under what conditions, and its presence is what makes the EUPL compliance checkable at the level of a particular installation rather than only in the source tree.

Where to look for help

The support structure is split in a way that tells you what kind of project this is.

The feature documentation is at evolveum.com/midpoint, and the product site is at midpoint.evolveum.com, which is where the documentation, the guides and the product pages live. The homepage given in the project details is midpoint.evolveum.com.

Bug tracking has its own system, at support.evolveum.com, and the README is explicit about it: for bugtracking system please go to that address. So issues are not filed on GitHub, which is a common arrangement for commercial-support open source products where the issue tracker carries customer details and account information.

The source code, by contrast, is entirely on GitHub at the Evolveum organisation, and the README gives the two repository locations for cloning, the HTTPS URL and the SSH form. The most recent source can be obtained from the Git repository, and the README is explicit that this is where to get it, which distinguishes it from the distribution packages.

That split between source and distribution is the practical takeaway. MidPoint is a product as well as a codebase, and the two are consumed differently. A developer working on the platform clones the repository. An organisation running the platform installs the distribution, and there are separate installation documents for the two cases.

The topic tags are short, identity-governance, identity-management, idm, iga and java, which is an accurate summary of the domain. The identity governance and identity management abbreviations are the two names the field uses for what this platform does, and the pair IGA and IDM covers the governance side and the administration side respectively.

The `CONTRIBUTING.md` file at the root, and the `docs/` directory alongside the `RELEASE-NOTES` and `milestone-notes.adoc` files, are where someone evaluating the project would look to understand how it is developed and how it is changing.

Editorial conclusion

Adopt MidPoint if your organisation has to manage access across several systems and needs to evidence who was granted what and when, since identity governance and audit reporting are the parts the platform is built around. Do not assume the documentation can be republished, because it is licensed CC BY-NC-ND and the source is under the European Union Public Licence rather than a standard permissive one, and check first whether your identity sources and target systems have connectors, since the provisioning side depends on the connectors available for them.

Frequently asked questions

Official sources

1. Evolveum/midpoint on GitHub
2. Issues
3. Project website
4. README