How midPoint policy-driven approvals route access changes
In midPoint, a request is the operation itself. When a user asks for a role, midPoint evaluates the policy rules that apply to that change, and it starts an approval process only when those rules say approval is needed. Teams that want role requests and sensitive changes approved without building a separate ticket workflow get the approval step attached to the change, so the request, the decision and the resulting access live in one record. midPoint then computes who the approvers are from the definitions you supply.
Teams usually need this when access changes are frequent enough that email or spreadsheet approvals break down, when the same role or resource needs different sign-off depending on sensitivity, or when auditors ask who approved a specific assignment and when. It is also useful when you already run midPoint for provisioning and want approvals to follow the same policy model rather than a second system with its own copy of the rules. If a change never requires approval under your policy, it should flow through without interrupting anyone.
Approvals do not replace the rest of the governance picture. midPoint does not decide your business rules for you: someone must define which roles need approval, who the approvers are for each role or resource, and what happens when an approver is absent. Evolveum describes the main configuration for approvals as defining approvers and policy rules, with the approval mechanisms predefined for a declarative approach. Access certification, which periodically re-checks whether existing access is still justified, is a separate activity. Your own organization still owns the decision criteria.
Before you commit to this design, confirm three things with your team. First, list the roles and sensitive resources that must be approved, and the approvers each one needs. Second, decide how a request behaves when no approver can be found or an approver is also the requester. Third, check how your current request tooling and identity sources will feed into midPoint. Confirm the exact approval behavior and configuration options for your midPoint release in the Evolveum approvals documentation, since behavior can differ between versions.
Approver and policy rule choices to settle before configuring
This table compares the three decisions that shape a midPoint approval design: who approves, which operations trigger a rule, and how strictly the rule applies. Read each row as a choice to settle with role owners and auditors before anyone edits configuration, because each option changes who owns an outcome and what evidence the approval history can show.
| Decision | Option | When it fits | What it means for ownership and audit evidence |
|---|---|---|---|
| Who approves | Role owners or designated business owners | Access to a business role has a clear accountable owner who understands what the role grants | Owner decisions are recorded against the request, so auditors can trace a grant to a named accountable person; confirm how owners are assigned to roles in your release. |
| Who approves | Line managers of the requester | Access follows reporting lines and managers know the day-to-day need better than a central owner | Ownership sits with a person who may not understand the target system, so review the approval history for rubber-stamping; the manager relationship must be current in the identity source. |
| Who approves | Designated group or other approver | Sensitive roles need a small, fixed set of approvers such as a security or compliance team | Concentrates accountability but creates a dependency and a potential bottleneck; document group membership and its review cycle as part of the control. |
| What triggers a rule | Role assignment that requires approval | Specific roles carry risk and every grant must be justified before it reaches a target system | Produces an approval record for each grant, which is the clearest evidence for access reviews; confirm the object and assignment types your rule can match in your release. |
| What triggers a rule | Self-service requests by the user | Users need to ask for access themselves and a central request path is required | The requester is recorded alongside the approver, so the justification and decision history form the audit trail; confirm how request forms and justifications are captured. |
| What triggers a rule | Other changes such as modifications or removals | Changes to attributes or removals of access also carry risk and need review | Broadens evidence beyond grants, but increases the number of approvals to design and staff; decide which change types truly need a review step. |
| How strictly the rule applies | Mandatory approval before the change takes effect | The change must not reach target systems until a named approver agrees | Strongest preventive control, with the approval outcome stored as the record of authorization; plan for escalation when approvers are unavailable. |
| How strictly the rule applies | Notification or review after the change | Low-risk changes where speed matters more than prior sign-off | Weaker preventive effect, so evidence depends on later review; pair it with access certification and document the compensating control. |
Scenarios where policy-driven approvals fit a role model
*Illustrative example:* a marketing analyst uses the midPoint self-service interface to request a reporting role that opens a finance dashboard. In midPoint, the request is the assignment operation itself. Policy rules evaluate that operation, and if approval is needed, midPoint computes the approvers and starts the approval process.
- Rule decision: a policy rule that triggers approval only for roles marked as sensitive, so low-risk roles can be granted without a ticket.
- Approver decision: the role owner, the requester's line manager, or both, set in the approver definition.
- Requester experience: whether the request form asks for a business justification and what the approver sees on screen.
- Required before go-live: a named owner for every requestable role, with a plain-language description the requester can understand.
- Fallback: what happens when the approver is absent, such as escalation to a delegate.
Confirm that every requestable role has a reachable owner who knows they are the approver before the first request is submitted.
*Illustrative example:* one platform administrator assigns the privileged administrator role to another administrator. Because the role grants broad control over a production system, the assignment must be signed off by someone outside the requesting team before it takes effect. The policy rule identifies the role as privileged, regardless of who requests it.
- Rule decision: privileged roles always trigger approval, including requests from administrators who already hold other privileged roles.
- Approver decision: a second approver, such as a security officer, who is not in the same team as the requester.
- Self-approval control: a rule that blocks an approver from approving their own request or a request from their direct reports.
- Required before go-live: a documented list of privileged roles, agreed by the security function and the platform owner.
- Evidence: the approval record should show who requested the role, who approved it, and when, so the trail can be reviewed later.
Check that the approver list resolves to people who can actually approve, because an empty or stale approver set stops the request.
*Illustrative example:* a user requests a group membership in a directory or an account on a finance application. The role itself may look ordinary, but the target system is sensitive. The policy rule matches the resource being changed, so approval applies to any role that writes to that system.
- Rule decision: a rule that tests the target resource, not only the role name, so the same control applies across roles that touch the system.
- Approver decision: the system owner, who understands what the access allows in the application, not only who the requester is.
- Scope decision: whether changes to the resource's own configuration need a separate approval path from changes to individual accounts.
- Required before go-live: a named owner for each target resource and a list of resources classified as sensitive.
- Operational detail: how approved changes are provisioned to the target, and how a failed provisioning attempt is reported back to the approver.
Confirm with the system owner which changes they expect to see in an approval request and which they consider routine.
*Illustrative example:* an HR system records a transfer from the accounts team to the procurement team. midPoint recalculates the employee's assignments from the new job code. Some of the resulting changes may be granted automatically, while others may need approval. The organization must decide in advance which is which.
- Rule decision: whether automatic changes triggered by an HR event bypass approval, require it, or require it only for sensitive roles.
- Approver decision: the line manager of the new position for requested additions, and the previous owner for removals where access should be confirmed.
- Timing decision: how long a pending approval can hold up the change, and what happens if the approver does not respond.
- Required before go-live: HR as the agreed source of record, a mapping from job codes to roles, and a named owner for each role in that mapping.
- Leaver handling: removals for departing staff should follow a path agreed with the business, so approval steps do not delay account removal.
Confirm with HR and the security function which HR events must complete without waiting on a person, before writing any rule.
Setup steps for midPoint policy-driven approvals
This sequence takes a midPoint release from a confirmed requirements record through approver and policy rule design to a promoted production configuration. Each step closes with a check that shows midPoint routes a request to the expected approvers and records the decision.
Confirm the midPoint release and requirements
Choose the midPoint release your organization will run and record it alongside its Java and PostgreSQL requirements from the midPoint system requirements page. midPoint 4.11 (Čapek) is a feature release planned for 21 October 2026, while 4.8 (Curie) is a long-term support release supported until 17 October 2028. midPoint recommends Java 25 for 4.11 and later and Java 21 for 4.10 and older, and it uses PostgreSQL as its native repository database. Ask the platform team to confirm the Java runtime, PostgreSQL version and database server layout against that page before any build starts. Done when a signed-off requirements record exists for the chosen release.
Build a non-production midPoint environment
The platform team installs midPoint in a non-production environment that mirrors the planned production layout, either on a Linux virtual machine or from Docker images. Run PostgreSQL on its own database server where possible, and confirm the Java runtime matches the release chosen in the previous step. Load a small set of test users and at least one role that represents a sensitive access decision, and label all of this data as test data. Verification: the web interface starts, an administrator can sign in, and the test users appear with the attributes you expect.
Define the approvers for each request
Work with the business owners of each role to decide who approves requests, for example the role owner, a manager relation or a named group. Evolveum describes approval mechanisms as predefined for a declarative approach, so the main configuration work is the definition of approvers and policy rules. Record each approver source in the design document together with the role it covers, and confirm that every approver group in the directory has a current owner. Verification: open a test user's assignment in the test environment and check that the approver definition resolves to the people you expect.
Write policy rules that trigger approval
The platform team writes the policy rules that decide when a change needs approval, such as assigning a sensitive role to a user outside a given department. Keep the first rule set narrow, covering one role or one resource, so its effect is easy to read in the logs. Confirm the rule syntax and approval options against the Evolveum approvals reference for your release, because the exact configuration depends on the version. Verification: review each rule with the business owner and check that it matches the intended role and no others.
Submit a test request with a test user
A test user requests a role assignment through the normal request path. midPoint treats the request as the operation itself, evaluates the policy rules and, if approval is needed, computes the approvers and starts the approval process. Use a test user who is not one of the approvers, then compare the approver midPoint computed for that request with the approver list from the design. Verification: the approval process starts, the computed approvers match the design, and the request stays pending until a decision is recorded.
Check the approval audit trail
Complete the first test request as the designated approver, then submit a second request and reject it so that both outcomes are covered. Confirm that the audit trail records who requested the change, which approver decided it, the decision and the time of each event. Compare the audit entries with the approval process view and check that the granted or refused assignment matches the recorded decision. Verification: a reviewer who did not configure the system can follow the full chain for both test cases and explain each entry.
Promote the configuration to production
Export the approver definitions, policy rules and related objects from the test environment and review them in a change record. Import them into production on the same midPoint release, Java runtime and PostgreSQL version confirmed in the first step, and keep a copy of the current production configuration so you can roll back. Run a controlled smoke test with an approved test account, then place the rule set under change control. Verification: the smoke test produces the same approver and audit entries seen in the test environment, and the business and security owners sign off the change record.
Security considerations for midPoint policy-driven approvals
Approval design tends to fail in a few predictable places. The cards below cover the risks an auditor will probe, and each one names the evidence that shows whether the control works. None of them claims that midPoint approvals satisfy a particular audit framework, since that depends on your scope and your assessor.
Requesters approving their own access
If the approver computed for a request can be the person making it, one approval removes the second check. Review how approvers are determined for role assignments, including managers and role owners, and confirm that the requester is excluded or that a different approver is required. Test it with a request made by someone who is also an approver. Evidence to keep: the approver definitions and the recorded result of that test.
Approval rules that match too much
A policy rule scoped by a broad condition can send sensitive roles through a light approval, or send routine requests to approvers who never review them. Check each rule's conditions against the roles and organizational units it covers, and record which rule applies to which role. Evidence to keep: exported rule definitions, the review that approved them and the mapping of roles to rules.
Bypass paths after configuration changes
Access can reach a target system without approval if an assignment is made directly, a mapping grants access outside the request path, or a rule is disabled during maintenance. Review change history for policy rules, approval settings and direct assignments, and rerun preview checks after each change. Evidence to keep: versioned configuration exports, change tickets and records of the checks that followed each change.
Access held by midPoint administrators
Administrators who can edit approval rules, approver definitions or role assignments can change the outcome of every approval, including approvals for their own access. Separate the administrative roles that change approval configuration from the roles that request or approve access, and limit who holds each one. Evidence to keep: the list of administrative role holders, their approval history and logs of configuration changes.
Authentication designed separately
Evolveum describes midPoint as an identity management system and states that it does not implement the server side of OAuth2, OpenID Connect or SAML. Decide how approvers and administrators sign in through a separate identity provider, and document its session and multifactor settings as their own design decision. Evidence to keep: the authentication design and the identity provider configuration used for midPoint's login paths.
Decision records for each approval
An auditor will usually ask who approved a specific request, when, on what basis and under which version of the rule. Confirm that midPoint keeps the request, approver decisions and comments in a form you can export and retain, and that the rule version in force at the time can be traced. Ask your implementation team to walk through a sample request from your own environment.
Running and testing approval rules after go-live
Once approvals are live, the approver definitions and policy rules are configuration, and they should change through the same change process as the rest of your midPoint configuration. A new rule or a changed approver alters who can approve a role request, so each change needs a named reviewer, a recorded reason and a test run before it reaches production. Keep the approval configuration in version control so that you can see what changed, when, and who approved it. Ask your team to confirm that the change process covers approval rules explicitly, because they are often treated as a lower-risk setting than role mappings when they are not.
Approval behavior also has to be tested after every midPoint upgrade. Use the midPoint releases page to plan versions, and note that midPoint 4.9 support ends 18 October 2026 and that midPoint 4.11 is planned for 21 October 2026. Before you move to a new release, run a fixed set of test requests in a non-production copy: a user requesting a role that needs approval, a request that is auto-approved, a rejection, and a request routed to a delegate or fallback approver. Compare the results with the outcomes you expect. Confirm approval behavior in your chosen release before upgrading, rather than assuming that the previous release's results still hold.
Approvers change roles, leave the organization and lose access, and a request routed to an approver who no longer exists or can no longer sign in will stall. Schedule a regular check that every approver referenced in your rules still resolves to an active identity. Your HR-driven lifecycle should disable departing people, but confirm how your configuration behaves when an approver is disabled: whether requests wait, fail, or move to a fallback. Decide in advance who receives escalated requests and make sure that role has its own coverage, so that no single person's departure blocks access decisions.
Ongoing ownership keeps this routine working. Name an owner for the approval rule set, and an owner for the test cases that accompany it. Store the test cases, the results from each upgrade and the sign-off record together, so that an auditor or internal reviewer can trace how a given approval path was verified. Your team may prefer to run these checks alone, or to bring in DeployOpen under an ongoing retainer for upgrade testing and continuous checks. Either way, agree in writing which party runs each test, who signs off each result, and how findings are tracked to closure.
Limits to confirm for your midPoint approvals
midPoint routes requests through approvals defined by policy rules, so the approval design is only as dependable as the platform behavior underneath it. The cards below list what to confirm against your own midPoint release, your approver model and your target systems before you commit to a design.
Operations the rule engine can intercept
Policy rules evaluate requests, so the first check is which operations your midPoint release routes through them. Confirm whether role assignments, direct attribute changes and resource-level operations each trigger evaluation in your version, and whether any operation you need to gate arrives outside that path. Test each operation type in a non-production environment before you write the approval rules that depend on it.
Behavior with multiple approvers
Confirm how midPoint computes approvers for a request, including whether approval requires one approver or several, and how it resolves approvers who are unavailable or hold the same role. Check how a rejection by one approver affects a pending request. Write these outcomes down as test cases, because the answers determine whether your segregation of duties rules hold under real conditions.
Timeouts and escalation
Ask what happens when an approver does not respond within the period you need. Confirm whether your release supports timeouts, escalation to another approver, or automatic outcomes, and whether a timed-out request is rejected, left open or approved. Document the default behavior, because an unanswered request that resolves silently is an access decision your governance team must be able to explain.
Retention of approval history
Confirm where approval decisions, comments and the request context are stored, and how long your deployment keeps them. Check whether history survives role removal, user deletion and database maintenance, and whether it can be exported for an auditor. Agree the retention period with your compliance owner before go-live, since the repository configuration and your backup schedule decide what is recoverable.
Connector support for each target system
Approvals gate changes that reach target systems through connectors, so check the connector for each system involved. Confirm the status of the LDAP, Active Directory and Microsoft Entra ID connectors, or any other connector you plan to use, in the Evolveum connector catalog, and confirm which operations and attributes that connector supports. An approved change that the connector cannot apply is an operational gap, not an approval result.
Java and database requirements for the release
Approval behavior depends on the midPoint release, and each release has its own runtime and repository requirements. Confirm the Java version and PostgreSQL configuration your chosen release requires, and check its support end date against your planned go-live and upgrade schedule. Test approval flows again after any upgrade, because rule evaluation and approval processing can change between releases.
Cost, effort and what midPoint approvals need from your team
What drives the cost of midPoint approval configuration?
The main drivers are scope, ownership and testing. Effort rises with the number of approval scenarios, since each scenario needs its own policy rule and escalation logic. It also rises with the number of approvers, the number of target systems the approved change reaches, the depth of testing you require, and how much of your role ownership is already defined. Where role owners are named and roles are documented, configuration moves faster. Where ownership is unclear, the first phase of work is often spent deciding who approves what. Ask any partner, including DeployOpen, to price the written scope item by item so you can see which driver moves the total.
Which parts of a midPoint approvals project are one-time and which recur?
Design, configuration and initial testing are one-time. Support, upgrades and rule maintenance recur. The one-time work covers defining approvers and policy rules, configuring them, testing approval paths and documenting the result. The recurring costs include an Evolveum support subscription if you choose one, retesting approval rules after role model changes, staff time to keep approver membership current as people move, and upgrade work across midPoint releases. Evolveum offers Product Support subscriptions with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions that add feature development and roadmap influence. Evolveum lists no prices on its support page, so request a quote for each subscription type.
How long does a midPoint approvals project take?
Duration follows scope, so the honest answer is a range set by your written plan. The schedule depends on the number of approval scenarios, the number of approvers and their availability to confirm decisions, the target systems involved, and how many test cases you need to sign off. Projects with settled role owners and a written approval policy usually spend less time in discovery than projects that must establish ownership first. Most engagements at DeployOpen are fixed-scope, and the scope, deliverables and timeline are agreed in writing before work starts. Ask for the timeline in the quote and check which dependencies on your side could pause it.
What must our team provide before approval configuration begins?
Your team supplies decisions, owners and access. Before configuration starts, you need named role owners for each role that will require approval, and a written approval policy that states who approves which request, in what order, what escalation applies when an approver does not respond, and which requests skip approval. You also need test accounts in the target systems, a non-production midPoint environment, and the source data that identifies people and their roles. Confirm who owns the approver lists after go-live, because most approval failures trace back to outdated membership rather than to midPoint itself.
Can our own team configure midPoint approvals without an outside partner?
Yes, if your team has the skills and time to own the work. midPoint is open source, and Evolveum states that it has no enterprise edition, so the software and its documentation are available to you without a license purchase. Evolveum's approvals documentation says the main configuration usually needed is the definition of approvers and policy rules, with approval mechanisms predefined for a declarative approach. Your team should understand policy rule evaluation, how approvers are computed, how to test approval paths, and how upgrades step through supported releases. Evolveum funds development through subscriptions, training and professional services, so ask about training before you decide.
Does Evolveum publish prices for midPoint support subscriptions?
No. Evolveum's support subscriptions page lists no prices. The Product Support subscription resolves product bugs with an 8x5 next-business-day or 24x7 SLA, and the Platform Subscription adds feature development and roadmap influence. To compare options, request a quote from Evolveum for the support level that matches your operating hours and risk tolerance. DeployOpen does not publish a price list either. A DeployOpen quote follows from a written scope that lists the approval scenarios, approvers, target systems and testing you need, so you can compare it directly with your internal estimate.
How do midPoint release dates affect an approvals rollout?
Choose a release line before you configure approvals, then plan for the next step. midPoint 4.8 (Curie) is a long-term support release supported until 17 October 2028. midPoint 4.10 (Braille) is a feature release supported until 26 November 2027, and midPoint 4.9 support ends on 18 October 2026. midPoint 4.11 (Čapek) is planned as a feature release for 21 October 2026. midPoint recommends Java 25 for version 4.11 and later, with Java 21 supported, and Java 21 for 4.10 and older, with Java 17 supported. Approval rules should be retested after each upgrade step, so record the release and Java version in the test plan from the start.
How DeployOpen works on this
DeployOpen plans, implements and documents midPoint policy-driven approvals inside your own infrastructure, starting from a written scope that names the request types, approvers and rules to be covered. Engagements are fixed-scope, so deliverables and timelines are agreed in writing before build work starts.
How we scope
- Inventory the change types that need approval, such as role requests, resource entitlements and attribute changes
- Agree the approvers for each request type, including managers, application owners and fallback approvers
- Define the policy rules that decide when an approval is required and which approval mechanism applies
- Record the written scope, deliverables and timeline before any configuration work begins
How we build
- Configure approver definitions and policy rules in a non-production midPoint environment first
- Test approval routing with requests that cover approve, reject and escalation paths
- Preview the effect of new policy rules before they apply to production accounts and roles
- Connect approval outcomes to the provisioning steps that follow in your target systems
How we hand over
- Document each approver definition, policy rule and the reasoning behind it
- Provide test cases and results showing expected routing for each request type
- Train administrators on maintaining approvers and rules as organizational roles change
- Deliver runbooks for approval backlogs, failed requests and changes to the rule set
How we support
- Offer ongoing support, upgrades and testing as a retainer after handover
- Review approver assignments and rules when teams, owners or policies change
- Plan midPoint upgrades so approval configuration is re-tested on each target release
- Confirm with Evolveum which support subscription fits your production obligations
