midPoint role model and access certification

Role explosion happens when every new application entitlement, department variant or project exception gets its own role. Within a few cycles the role catalog holds hundreds of narrow roles, each assigned to a handful of people, and the reviewer facing a certification campaign sees thousands of role assignments with no obvious meaning. The fix starts before the first campaign launches. Decide how business roles, application roles and archetypes will be separated, and agree which of them a reviewer is expected to certify. A role model that a reviewer cannot read will be rubber-stamped, and that defeats the audit evidence the campaign is meant to produce.

Naming conventions and archetypes do most of the consolidation work. Set a naming pattern for roles that encodes the function, the scope and the owner, so that a reviewer can tell a job-function role from a technical entitlement role at a glance. Use archetypes in midPoint to classify roles and users consistently, so that reporting and campaign scoping can filter by type instead of by free-text description. Group application roles under the business roles that need them, and keep the number of business roles tied to job functions rather than to individual teams. Document the naming rules and the archetype definitions in the same place as the role model, and make them a gate for any new role request.

You cannot manage what you do not count. Build reports in midPoint that show the number of roles by archetype, the number of assignments per role, roles with zero or one assignment, and users who hold many roles that overlap in entitlements. Review these reports on a fixed cadence, before each certification campaign is scoped, not after reviewers have already flagged problems. Ask the identity team to confirm which report fields and report objects are available in the midPoint version you run, because report capabilities differ between releases and should be checked in your own environment rather than assumed.

Retire or merge a role when its assignment pattern no longer justifies a separate object. Typical signals are roles with very few assignments that duplicate the entitlements of a larger role, roles whose owner has left or cannot be identified, and roles created for a project that has ended. Merging requires a plan: identify every user who holds the old role, confirm that the surviving role grants the same access, and schedule the change so that access is not removed by surprise. Retiring a role should also trigger a review of any approval policy or certification definition that references it. Agree on these steps with the role owners and the business approvers before any change is made.

Expect this work to recur. Role consolidation is not a one-time cleanup, because the organization keeps changing and new applications keep arriving. Assign an owner for the role catalog, set a periodic review of the reports described above, and ask your implementation partner to show how the naming rules and archetypes will be enforced during role requests. Ask for the review cadence and the ownership model to be written into the scope of any fixed-scope engagement, so that the work of keeping the model reviewable is planned and paid for as part of the project, not left to the reviewers who will inherit the problem.

The role model and certification campaigns are only credible if you can show, with repeatable tests, that midPoint grants the right access, routes approvals to the right people, removes access when a reviewer says no, and escalates campaigns that stall. Start by writing a test pack before the first production campaign. Each test should name the input (a sample identity, a request, a campaign definition), the expected outcome, and the place where the outcome is recorded. Run the pack in a non-production environment that carries the same role definitions, assignment policies, approval schemas and connector configuration as production, because a test against a simplified copy proves little about the real configuration.

Begin with role assignment outcomes. Choose a set of sample identities that cover each business role, each application role and the edge cases your HR source produces, such as a person who changes department mid-cycle, a contractor with an end date, or someone who holds two roles that conflict under your assignment policy. For each sample, record which roles midPoint assigns, which it refuses, and which it marks for approval. Compare these outcomes with the written role catalog that your business owners signed. Where they differ, the cause is usually an inducement, an assignment condition or an object template, and each of those should have its own test case. Confirm that a change to the HR attribute that drives the assignment produces the expected removal as well as the expected grant.

Next, test approval routing and revocation. For each approval path, submit a request as a sample requester and confirm that the approver set matches the policy, that a second approver is requested where the policy requires one, and that the request times out or escalates as configured. Then reject a request and check that no assignment is created, and reject a previously granted access during a campaign and check that midPoint removes the assignment on the target system, not only in its own repository. This last check is where many programs find gaps, so compare the account state on the target system with midPoint's view of the same identity. Keep the reviewer identity, the time and the decision text for every rejection.

Campaign completion and escalation need their own tests. Define a small campaign over sample accounts, let the reviewers ignore it, and confirm that reminders, escalation to a fallback reviewer and the final default action all fire at the intervals your governance policy states. Confirm what happens to items that remain undecided at the deadline, because the default action is a control decision that your risk owner must approve. Finally, reconcile decisions with the target systems. After each campaign, run a reconciliation to detect accounts that exist without a corresponding decision and decisions that were not applied. Investigate every discrepancy, document the root cause and rerun the test until the difference is zero or explicitly accepted.

For auditors, keep a consistent evidence set for each campaign and each change to the role model. This should include the approved role catalog version, the campaign definition and its scope, the reviewer assignments, the decision records with timestamps and reviewer identities, the escalation and default-action logs, the reconciliation report with its exceptions and their closure, and the results of the test pack before and after each upgrade. Confirm with your auditor which format and retention period they expect, and confirm that midPoint's audit and log settings in your deployment capture these records before the first campaign runs. DeployOpen can prepare the test pack and evidence templates, but the independent assessment of whether the controls are adequate remains with your auditor.