midPoint role mining: where to start a role model from years of accumulated access
Many organizations have run applications for years, and every one of them has accumulated role assignments that were granted one request at a time. The result is a directory full of application roles, a few informal business groups nobody fully trusts, and no clean business role model to build on. midPoint role mining analyzes application roles and their assignments to users, detects clusters and patterns in who holds which combinations of access, and suggests candidates for business roles. Teams need it when they want to start a role-based access model but cannot define business roles top down without first seeing what people actually hold.
Evolveum's stated motivation for role mining follows that problem. Business roles are hard to define from the top down, because the people who could describe them are rarely the ones who can see every application entitlement. Meanwhile application role assignments tend to accumulate, so the gap between what a role model says and what users hold keeps growing. Mining starts from the assignments that exist and asks which groups of users share a stable set of access. The approach simplifies role-based access control by giving the team a data-driven starting point rather than a blank page.
The output of role mining is a set of candidates for review, not finished roles. A candidate cluster may be correct, may combine access that should be split, or may reflect one team's historical exceptions. Each candidate needs an owner from the business who can confirm what the role means, which applications and entitlements it should contain, and who should be allowed to request it. Plan for a review cycle in which rejected candidates are documented, not silently dropped, because the reasons often reveal policy gaps. Ask your implementation partner how candidate review, approval and sign-off will be recorded before any role is assigned in production.
Before running mining, confirm the input you will feed it. Identify which target systems and application roles are in scope, how complete the user-to-role assignment data is for each, and whether dormant or orphaned accounts will distort clustering. Decide how much noise you will accept, since a cluster that covers a handful of users may not justify a business role. Also agree on what a successful first pass looks like, such as a shortlist of candidates a business owner can evaluate, rather than a complete role catalog. These decisions shape the result more than the mining algorithm does.
The midPoint documentation for role mining sets out the feature and its configuration. Read it alongside your own data inventory, and confirm with Evolveum or your partner which mining options your midPoint version supports before you plan the work around them. The source repository is the place to check the code behind a feature when your team needs to verify behavior for itself.
Mining configuration choices and when each fits
This table compares the three main configuration choices a team makes before running midPoint role mining: which roles and assignments enter the analysis, how much history and which identity sources feed it, and how candidate roles are reviewed before adoption. Read each row for the fit and the trade-off, then use the Evolveum role mining documentation for exact settings in your midPoint version. The main takeaway is that a narrower, cleaner input set produces fewer but more trustworthy candidates, while broader input produces more noise to review.
| Choice | Fits when | Trade-off | What to confirm |
|---|---|---|---|
| Application role scope | You want to start with one system or business unit whose application roles are well understood | Scope versus noise: a narrow scope gives clusters that are easier to explain but misses roles that span systems | Which resources and application roles the mining run reads in your version |
| Application role scope (broad) | Access is spread across several connected systems and you need to see cross-system patterns | More candidates and more noise, so review effort rises quickly with each added system | How the mining run handles roles from multiple resources and how to filter them |
| Assignment history depth | Access has changed over time and you want recent, active patterns to drive the candidates | Speed versus coverage: a shorter window runs faster and reflects current work, but may hide rarely used but legitimate access | Whether the analysis reads current assignments only or includes historical data in your deployment |
| Identity sources | Your HR or authoritative source is reliable and job attributes can group users meaningfully | Richer attributes help explain clusters, but inconsistent source data creates false groupings | Which user attributes are available to mining and how they are mapped from each source |
| Candidate review before adoption | Business owners must approve roles before they change access, which is typical in regulated environments | Review effort versus speed: a full review of each candidate is slower but gives defensible decisions | How candidates are exported, reviewed and promoted to business roles, and whether approvals are routed through midPoint policy |
| Iterative mining cycles | You expect the first run to reveal gaps in scope or data and want to tune the inputs | Speed versus rework: repeated runs refine results but each cycle adds review time | How to compare runs and track which candidates were accepted, changed or rejected |
How to run a role mining exercise in midPoint
The sequence below moves from a confirmed platform baseline to business role candidates that owners have approved and that enter midPoint through its normal change path. Each step closes with a check, so the candidates you carry forward rest on accurate assignment data and recorded decisions.
Confirm the midPoint version and runtime requirements
Choose the midPoint release you will mine against and confirm its Java and PostgreSQL requirements before any data moves. Evolveum's current guidance recommends Java 21 for version 4.10 and older, with Java 17 supported, and Java 25 for version 4.11 and later, with Java 21 supported. Confirm the PostgreSQL version and whether the repository runs on a separate database server, which the project recommends. Check: the platform team records the midPoint, Java and PostgreSQL versions in the scope file, and each value matches the current requirements for that release.
Connect source systems through ConnId connectors
Connect each application that holds role assignments to midPoint through a ConnId connector so the assignment data is current. Typical sources include LDAP or Active Directory, Microsoft Entra ID, database tables and SCIM endpoints, and you should confirm each connector's support status in the Evolveum connector catalog before relying on it. The integration owner runs an initial reconciliation for each resource. Check: the account count midPoint holds for each resource matches the count in the source system taken on the same day, and any difference is explained before mining starts.
Agree scope, owners and mining objectives
Decide which applications, user populations and time windows are in scope, and name an accountable owner for each application and business area. Write down what the exercise should produce, such as candidate business roles for a defined group, and what it will not change in the live environment. Agree who approves a candidate and who resolves disputed assignments. Check: a signed scope note lists every resource, owner and approver, and the security or compliance lead has accepted it before analysis begins.
Run mining in a controlled environment
Run role mining on a copy of the agreed population in a non-production or otherwise controlled environment, so exploring clusters cannot change live accounts or assignments. The identity engineer runs the mining job on the scoped data and records the parameters used, so the run can be repeated and compared. Keep the source snapshot read-only for the duration of the analysis. Check: the assignment counts in the controlled environment match the production snapshot it was taken from, and the parameters and output are stored with the scope note.
Review clusters with business owners
Walk each proposed cluster with the business owner of the application or function it affects. The owner confirms which users need the access, flags assignments that accumulated over time without a current need, and marks clusters to split, merge or drop. Record each decision against its candidate, including the reason for any rejection. Check: every candidate carries a sign-off from its named owner, and the review log lists all rejected and unresolved clusters with a next action and an owner.
Turn accepted candidates into roles
Convert each accepted candidate into a role definition that states its included assignments, membership logic and owner, then submit it through the same change path used for other midPoint changes. Preview the effect on existing users before approval, and route the role through whatever approvals your policy requires. Check: each role is approved through the normal change path, and after rollout the entitlements held by affected users match the accepted candidate, with any exceptions logged for follow-up.
What role mining changes in your role model and what it does not
Role mining gives you candidate roles, not approved business roles. The midPoint role mining function analyzes application roles and their assignments to users, looks for clusters and patterns, and suggests groupings that could become business roles. A cluster tells you that a set of people already holds a similar combination of access. It does not tell you what job those people do, whether that combination is appropriate, or what the role should be called. Treat every mined output as a proposal that enters your role model only after a named business owner has defined what it means and confirmed its contents.
The main risk is that mining reproduces the past. Application role assignments accumulate over years, and Evolveum describes this accumulation as the reason role mining exists in the first place. If a cluster is built from access that people received through old transfers, temporary projects or one-off exceptions, the mined role will carry that excess forward. Accepting such a candidate without review turns over-privileged assignments into a formal business role that looks legitimate in the model. Before accepting any candidate, compare each proposed role member by member against the current job, and flag any entitlement that the role owner cannot justify. Plan to remove or re-scope those entitlements as a separate, tracked change rather than letting the mined role absorb them silently.
Decisions that mining cannot make belong to the business. Someone must decide the scope of each role, the naming convention, the owner, the approvers for requests, the review frequency and the rule for when a person should hold the role instead of a narrower one. These decisions shape how midPoint assigns access going forward, so they should be recorded alongside the role definition before the role is activated. Ask the business units who must sign off, and document what each approval covers. Approval routing and certification are configured separately, so this section does not replace those decisions; it defines what the role is for.
Role mining also does not change how people sign in. midPoint is an identity management system. Evolveum states that it is not an access management or SSO server and does not implement the server side of OAuth2, OpenID Connect or SAML, although its own user interface can authenticate against external SSO services. A mined role model decides which entitlements an account should hold. It does not decide how the user proves identity to an application or how sessions, multi-factor authentication or token lifetimes work. Confirm early which product will act as the identity provider for your applications, and design the authentication path separately so that the role model is not mistaken for an access control layer it cannot provide.
Security and operational risks of mining existing access
Role mining reads the access people hold today, so it inherits every excess privilege and data exposure already in the environment. The cards below cover the data and review risks to control before analysis starts, plus the midPoint deployment items that keep mining runs and role changes recoverable.
Excess privileges in current assignments
Mining groups assignments as they exist, so a cluster can reflect privileges that were granted for a past project and never removed. A proposed business role built from that cluster can quietly carry those privileges forward. Before accepting a candidate, check each application role in the cluster against its owner and its current business need, and treat any unexplained privilege as a finding to resolve rather than a pattern to preserve.
Sensitive data in exported assignment sets
Assignment sets name users, their roles and often their departments, which makes them sensitive in their own right. Mining output and any spreadsheet or file exported from it should be classified like the identity data it came from. Confirm where exports are stored, who can download them, and how long copies persist, and limit the working set to the attributes the analysis actually needs.
Who may view and approve candidates
A candidate business role is a proposal about who should hold a bundle of access, so the people who can see candidates and the people who can approve them shape the result. Define viewing rights for mining results separately from rights to create or change roles in midPoint. Confirm that the approvers of a candidate are not the same people whose assignments produced it, unless your policy explicitly allows that.
Separation of duties during review
Review of mined candidates is an access decision, so it needs the same separation you apply to access requests. The person who runs the mining, the person who edits the candidate and the person who approves it should be different roles where your control framework requires it. Document who performed each step so the review trail shows that no single operator both proposed and accepted a role.
Retention of analysis outputs
Each mining run produces clusters, candidate lists and intermediate results that can outlive the project that generated them. Old candidates may be mistaken for approved roles, and stale analysis may reflect access that has since changed. Set a retention period for mining outputs, label runs with the date and scope of the data they used, and remove or archive results that have been superseded.
Mining against production data
Mining reads live assignments from the environment midPoint manages, so running it against production adds load and exposes production identity data to whoever operates the analysis. Decide whether runs happen on production data, a restored copy or a reduced extract, and record that choice with the run. Confirm with your team how the analysis environment is access-controlled before any production read takes place.
Repository backups before role changes
Accepting candidates changes how midPoint assigns access, and the repository is where those changes are recorded. Take and test a repository backup before applying a batch of role changes so the state can be restored if the batch produces unintended removals. Confirm your backup schedule and restore procedure against the midPoint documentation for your release before the first change window.
Sticky load balancing, shared database and Quartz
Multi-node midPoint deployments depend on a sticky HTTP load balancer, a shared central database, cache invalidation between nodes and Quartz for distributed task scheduling. A mining or reconciliation task that is scheduled on one node runs once across the cluster rather than on every node, so verify the scheduler configuration before relying on a run. Check the load balancer stickiness settings and the database connection setup as part of the pre-change review.
Which midPoint release to plan role mining on
Choose the midPoint release line before the role mining project starts, because the support dates decide how long the candidate roles and the tooling around them stay on a supported platform. The midPoint releases page lists 4.8 (Curie) as a long-term support release, supported until 17 October 2028. It lists 4.10 (Braille) as a feature release supported until 26 November 2027. Support for 4.9 ends on 18 October 2026, so it is a poor base for new mining work. The page also plans 4.11 (Čapek) as a feature release for 21 October 2026.
A role mining project usually produces business roles that the organization will keep for years, so the release should be supported for the whole path from analysis to first production rollout. Map your planned dates against the support windows. If go-live is likely to fall after 26 November 2027, a 4.10 base means you will need a later upgrade during the project or soon after it. The 4.8 line gives the longest window. Confirm the dates on the releases page on the day you decide, because the schedule may change.
The Java runtime also shapes the choice. midPoint recommends Java 25 for version 4.11 and later, with Java 21 supported. For 4.10 and older it recommends Java 21, with Java 17 supported. Check which JDK your application servers, container images and patching process can run before you select the release. Changing the JDK later means rebuilding the midPoint nodes and retesting the mining configuration, so the platform team should settle this before the analysts start building role candidates.
Evolveum sells two kinds of subscription. Product Support subscriptions cover resolution of product bugs, with an 8x5 next-business-day SLA or a 24x7 SLA. Platform Subscriptions add feature development and influence on the roadmap. The support page lists no prices, so request written quotes. Ask which release lines each subscription covers, what support looks like after a release reaches end of life, and whether the SLA hours fit the change windows you use for approving new business roles. Subscription fees recur, while the implementation work is usually a separate, one-time cost.
Write the release decision into the project plan with four items: the target release, the JDK version, the database version and the planned go-live date compared with the support end date. Record who owns the subscription and who approves an upgrade if a bug fix requires one. Treat this record as a project input, not an afterthought, because a mined role model that depends on an unsupported release is hard to defend in an access review.
Role mining cost, time and what your team must provide
What drives the cost of a midPoint role mining project?
The main cost driver is how much access data has to be analyzed and reviewed, not the mining run itself. The factors that move effort most are:
- The number of applications and directories whose role assignments are in scope
- The volume of assignments per user and the number of distinct entitlements
- How clean the source data is, including duplicate accounts and inconsistent naming
- How many business owners must review candidate roles, and how many review rounds are needed
- Whether connectors to the source systems already exist and are tested
Each of these changes the amount of scoping, data preparation and review time. Ask any provider to break the quote into those factors so you can see which ones you can reduce before the work starts.
Is midPoint role mining a one-time cost or an ongoing cost?
The discovery and role mining work is a one-time project cost, while midPoint itself is open source with no license fee to pay. Recurring costs usually come from the following:
- Ongoing role maintenance as applications, teams and job functions change
- Support subscriptions from Evolveum, which resolve product bugs under an 8x5 or 24x7 service level, if you choose to buy them
- Platform subscriptions from Evolveum, which add feature development and roadmap influence, if you choose to buy them
- Infrastructure, database hosting and upgrade effort for the midPoint deployment
Evolveum's support subscription page lists no prices, so confirm current subscription costs directly with Evolveum before comparing options.
What does our team need to provide for a role mining engagement?
Your team must provide read access to the source systems, named business owners who can review candidate roles, and the identity data owners who can explain existing assignments. In practice, that means:
- Read-only exports or access to the application role assignments being mined
- Access to the authoritative user and HR data needed to match people to job functions
- Business owners for each application or department who can accept, reject or rename proposed roles
- A decision-maker who approves the role model before any role is assigned in production
Plan these people early. Review availability is often the constraint that sets the calendar, more than the analysis itself.
Can our own team run midPoint role mining without a partner?
Yes, a capable internal team can run role mining with midPoint, provided it has midPoint skills and enough time. The mining feature analyzes application roles and their assignments to find clusters that can be proposed as business roles, so the technical work is within reach of engineers who already run midPoint. A partner typically adds value in these areas:
- Scoping the first pass so it covers the systems that matter most
- Structuring the review process so business owners give consistent decisions
- Defining acceptance criteria for proposed roles and documenting the outcome
- Bringing experience from earlier engagements to avoid common data-quality traps
The right choice depends on your team's current capacity and on how many business owners must be coordinated.
How is a midPoint role mining engagement quoted?
DeployOpen does not publish a price list. Most engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts, and a quote follows from that written scope. To compare quotes, ask each provider to state:
- The systems and assignment volumes included in the mining run
- Who performs data preparation, the mining analysis and the review workshops
- The deliverables, such as candidate role catalogs and documented review decisions
- Which items are one-time and which are recurring, such as support or ongoing role maintenance
- What is excluded, including connector development and production role changes
A written scope with these items makes quotes comparable across providers.
What data quality problems slow down role mining?
Data quality problems usually slow the work more than the mining itself, because unclear inputs produce unclear candidate roles. Common issues to check before the project starts include:
- Orphaned or duplicate accounts that inflate assignment counts
- Application roles with inconsistent names or no owner
- Assignments that were granted directly to users instead of through groups
- Missing or stale job function or department attributes in the HR source
- Gaps in connector coverage, where some systems can only be read through manual exports
A short data profiling step before scoping helps you estimate the cleanup effort. Confirm with your identity data owners how each of these issues is handled.
Which midPoint version should we confirm before starting role mining?
Confirm the midPoint version and its support window before scoping, because support dates affect when upgrades must happen. Evolveum lists midPoint 4.8 (Curie) as a long-term support release with support until 17 October 2028, midPoint 4.10 (Braille) as a feature release supported until 26 November 2027, and midPoint 4.9 support ending 18 October 2026, according to the midPoint releases page. Also confirm with your team:
- The Java version and PostgreSQL repository version the deployment runs on
- Whether a planned upgrade would change how role mining results are stored or reviewed
- Which connectors the mining scope depends on and their support status in the connector catalog
If an upgrade is due during the project, agree the sequence in the written scope.
Where to verify role mining behavior
Before you scope a role mining effort, confirm how the feature behaves in the midPoint release you plan to run. The Evolveum role mining documentation describes how midPoint analyzes application roles and their assignments to users, detects clusters and patterns, and suggests candidates for business roles. Read it alongside the configuration you intend to use, because the sections on analysis inputs, clustering options and how candidates are presented back to reviewers are the parts most likely to shape your work plan and your reviewers' workload.
The midPoint releases page is the second check. It lists which versions are long-term support releases and which are feature releases, and it gives support end dates for each. Role mining behavior can change between feature releases, so a capability you rely on in one version may be documented differently in another. If your organization needs a long support window, compare the support dates on the releases page against the time you expect the role model project and the follow-on governance work to take.
The midPoint system requirements page is the third check. Role mining runs against the same repository, Java runtime and node layout as the rest of the deployment, so the Java version, database requirements and multi-node guidance for your chosen release affect how and where the analysis runs. Confirm these with your platform team before you commit to a release, since a version that requires a runtime your standards do not yet allow will add work that the scope should reflect.
Before you scope the engagement, write down the exact midPoint version, the features you expect to use for role mining, and the documentation section that describes each one. Ask the implementation partner to confirm in writing that those features are available and behave as documented in that release, and ask what changes if you need to move to a newer version during the project. A written confirmation of feature availability protects the scope, the acceptance criteria and the timeline from assumptions about behavior that may not hold in your environment.
Also confirm the details that the documentation may leave to your environment: the size and age of your application role assignment data, how identity sources feed midPoint, and whether your review process has the time and owners needed to validate proposed business roles. Treat the documentation as the authority on how the feature works, and treat your own test run against a copy of your data as the authority on what it will produce for your organization.
How DeployOpen scopes and delivers midPoint role mining
DeployOpen approaches midPoint role mining as a scoped piece of identity governance work inside infrastructure you control. We start from your existing application role assignments, agree the outputs in writing, and deliver candidate business roles that your owners review before anything changes.
How we scope
- Inventory the application roles, sources and user assignments that role mining will analyze in midPoint.
- Agree in writing which systems are in the mining dataset and which are excluded for this phase.
- Define the review criteria owners will use to accept, change or reject proposed business role candidates.
- Confirm the midPoint version, database and hosting model before any mining work begins.
How we build
- Connect the source systems to midPoint through the connectors your environment requires, then validate the data read.
- Run role mining analysis and record the clusters and patterns it produces for each application.
- Test candidate business roles in a non-production midPoint configuration before any production use.
- Document the mining method, assumptions and exceptions so the results can be reviewed and reproduced.
How we hand over
- Deliver the candidate role catalog with the assignments each candidate would grant and the evidence behind it.
- Provide the decision log showing which candidates owners approved, changed or rejected, and why.
- Hand over runbooks for repeating the mining cycle, plus knowledge transfer sessions for your identity team.
- Confirm the handover checklist against the agreed scope before the engagement closes.
How we support
- Offer ongoing support and upgrade work as a retainer if you want DeployOpen to repeat mining cycles.
- Plan midPoint upgrades across the releases you run, stepping through supported versions for your environment.
- Review role candidates again when application roles change, so the role model does not drift from reality.
- Ask DeployOpen to confirm the support scope, response expectations and retainer terms in the written quote.
