One Identity Manager vs midPoint

The practical question is how each product runs a periodic access review and acts on the result. In One Identity Manager, attestation is typically configured as policies that select the access to be reviewed, the approvers responsible for it, and the actions taken on denied items, with decisions written back to provisioning. In midPoint, the equivalent work is access certification: certification definitions set the scope, reviewers are assigned through reviewer rules, and remediation revokes or changes the assignments that a reviewer rejects. The sibling page on attestation maps these objects in detail. Before you accept any mapping, ask One Identity to confirm how it handles reminders, escalation, delegation and reviewer changes, then test the same cases in a midPoint sandbox and confirm which ones need custom work.

Role-based access control is where the two designs diverge most, and the role model has to exist before either product is configured. One Identity Manager organizes access through its own role concepts, such as business roles, system roles and application roles, along with organizational structures that feed them. midPoint models roles as objects that carry assignments, with inducements and policy rules that decide what a role grants. Either way, you need a written inventory of entitlements per target system, a named owner for each role, a naming convention, and a rule for which roles may be combined. Separation of duties constraints must be defined before the first role is created. Role mining output is useful evidence for drafting this model, but it proposes candidates and does not decide which roles the business should approve.

Run the role model through a single business unit before expanding it. Pick a department with clear ownership, define its roles on paper, and record how many exceptions the model produces during a test review. Those exceptions show whether the design is ready for attestation, and they tell you how much rework a migration would require. Confirm with each vendor how role changes are versioned and approved, and whether a role change triggers a re-review. Do not assume that a role model built for One Identity Manager will translate one to one into midPoint objects. Plan for a translation step, verify it with the business owners, and keep the signed-off model as the evidence that auditors will ask for.

The licensing difference is the first thing to put in front of procurement. midPoint is published under the European Union Public License (EUPL-1.2), with Apache 2.0 as a secondary license, and Evolveum states that it has no enterprise edition: every line of midPoint code is open source, and the project describes itself as open source, not open core. That means the platform itself carries no license fee. Evolveum funds development through subscriptions, training and professional services, with midPoint developers working on it full-time. Your recurring cost is therefore the support and services you choose to buy, plus the infrastructure and staff to run the system. Ask Evolveum to confirm the license terms that apply to your intended use and to any bundled components before you rely on them in a contract.

Evolveum offers two kinds of subscription. Product Support covers resolution of product bugs, offered with an 8x5 next-business-day or 24x7 SLA. Platform Subscriptions add feature development and roadmap influence on top of support. Its support subscriptions page lists no prices, so the cost has to come from a written quote. Compare the SLA tier with your own incident process, because a next-business-day response may not match an identity outage that blocks joiners or revokes access overnight. Also ask whether a Platform Subscription would fund features your attestation or role model needs, since that is the decision point between buying support and buying influence over the roadmap.

Self-hosting changes where identity data and audit evidence live. With midPoint running in your own cloud account, data center or air-gapped network, the repository, reconciliation results, certification campaigns and audit logs stay under your control, and you decide retention and access to them. Confirm with your assessors which evidence they will accept from the platform, how it is exported, and who holds the database backups. Also note that midPoint is an identity management system, not an access management or SSO server. It does not implement the server side of OAuth2, OpenID Connect or SAML, although its own user interface can authenticate against external SSO services. Plan your sign-on and token issuance separately, and check that your existing identity provider can serve the applications that midPoint provisions to.

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers or air-gapped networks. For a team weighing One Identity Manager against midPoint, the practical starting point is a scoped evaluation agreed in writing before any work begins. That evaluation can test the decisions that matter most in this comparison: whether the target systems you rely on are covered by ConnId connectors, how your attestation campaigns map to midPoint access certification, and whether your Java and PostgreSQL operations team can run the platform. Scope, deliverables and timelines are set out in the agreement, and a quote follows from that scope.

Once the evaluation supports a decision, DeployOpen can plan the migration: inventory of One Identity Manager policies, approval flows and connectors, a target design for midPoint roles and policies, and a cutover approach that runs both systems in parallel for a defined period. The migration plan should name who owns each connector, which access reviews must be completed before cutover, and what evidence an auditor will ask for afterward. DeployOpen prepares these systems, controls and records for compliance assessments, but independent auditors and certification bodies issue any audit report or attestation. Security testing of the resulting deployment, covering the midPoint application, its APIs and the connector credentials, is available as a separate fixed-scope engagement, and ongoing support, upgrades and continuous testing can be covered by a retainer.