The governance model rapidvalue.eu →

Roles and role mining

Anyone who has lived through a role-engineering project knows the shape of it: months of workshops, a role catalogue nobody recognises, and an estate that carried on granting access directly the entire time. This page is the model behind the alternative, and its limits. The short version: the platform reads the access people already hold, proposes candidate roles with the evidence attached, and then makes a named human owner and a reviewer chain the only route by which any of it becomes real.

What a proposal is

A run reads every grant the platform has correlated to an identity and applies eight grouping strategies, each a separate named rule: an identity-type baseline (all employees, all contractors), internal versus external, organisational unit, context membership, job function, context hierarchy (an org unit with or without its subtree), permission clustering (start from a permission, find the cohort that dominates its holders), and a two-attribute combination such as department × location. Two further detectors look at roles you already have: one proposes extending a role whose members have all quietly acquired the same extra permission, the other proposes formalising people who already hold everything a role contains but were never given the role.

The strategies are deliberately separate and deliberately dull. There is no model that learns; there is no cluster identifier. An auditor asking "why is this a role?" gets one sentence back — this cohort is department = Finance and identity_type = employee, found by the organisational-unit rule — and that sentence is the whole derivation.

Each proposal carries per-entitlement evidence rather than a verdict:

A confidence figure sits on top, weighted half on average coverage, three-tenths on average exclusivity and two-tenths on cohort size, capped at twenty members. It is a formula, printed as a formula. It ranks proposals against each other; it does not claim a probability that the role is correct.

That is what "framed as an opportunity" means concretely. A run does not produce the role model to be accepted or rejected as a whole. It produces independent candidates, each defensible on its own evidence, and you take the ones that hold. The rest cost nothing to leave.

One exclusion is worth stating because its absence caused a real defect: already- formalised roles never re-enter the candidate pool. Role membership is projected into the access model as an ordinary grant, so without the exclusion the next run saw a formalised role as a permission held by 100% of its own members and nobody else — a perfect candidate — and proposed a role wrapping the role. The exclusion is by entitlement category, not by naming convention.

Coverage, before and after

Every run reports coverage before and after. Both numbers are computed on one scale and one denominator: all correlated grants in scope.

Before is the share of those grants carrying at least one Expected-access source — a policy, a role, an approved request, an explicit administrative keep. A grant with none is access that exists in a target system for no recorded reason.

After is the union of two sets over that same denominator: the grants already covered, plus the grants a member would newly hold through a proposal's default include set. Because it is a union with the baseline, "after" can never be lower than "before" — accepting a proposal can only add explanation, never remove it.

This is stated so precisely because the first version was wrong in a way that read as a product defect rather than an arithmetic one. It counted only the newly explained grants and divided by a different denominator — distinct identity/entitlement pairs rather than grants — so a run could report coverage falling from 0.1% to 0%, which is not a bad result but an impossible one.

What the figure does not promise: it projects the effect of accepting every proposal in the run at its default include set. Accept three of eleven and you get roughly three elevenths of the story. It is a projection over a hypothetical, not a forecast.

A role needs an owner before it can exist

Formalising a proposal without a role owner is refused by the server, not merely discouraged by the interface. Both routes are gated: the one-click formalisation on the mining page, and the path where a role is built in the role wizard and then linked back to the proposal. Either returns an unprocessable-entity error naming the missing owner.

The reasoning is not tidiness. A role with no owner has nobody to start its approval chain, nobody to answer for it at recertification, and nobody who notices when it outlives the project that asked for it. It will still be granting access in three years, and the first person to ask why will be an auditor. The gate exists because an unowned role is the exact artefact a role-engineering project leaves behind.

The owner is polymorphic: a person, an IGA group (a pool, so departures do not orphan the role), or a context owner — ownership by reference to an organisational unit, so turnover follows the org chart rather than requiring a handover. A business role type is required alongside it, because the type is what carries the governance defaults the role inherits.

This is also where "one click" is and is not honest. A role type may name a default owner group, and formalisation resolves it — genuinely one click. A role type whose default is an identity or a context carries no value to resolve, so it still requires a choice. Bulk formalisation above a confidence threshold runs the same gate per proposal and collects per-proposal errors rather than failing the batch: proposals whose role type names a group go through, the others come back named, and nothing is silently skipped.

The chain comes from the role type, not from the run

The reviewer chain for a formalisation resolves in one authoritative order, shared by every path that creates a role:

  1. An inline override set by the administrator on the formalisation screen.
  2. The role type's chain — either a named chain from the central registry, or the type's own inline chain.
  3. The tenant's registry default for role certification.
  4. A single-step manager fallback, so a path always exists.

Mining generates no chain of its own. It used to, and that is the point: a role's chain was defined in three unaligned places and the least visible one won. A "Baseline" role type configured to route to the role owner then the IAM team was overridden by a chain the mining algorithm had hard-coded to security, so the configuration an administrator could see was decoration. Proposals now leave the field empty and fall through to the type. The correction is forward-looking; proposals created before it still carry their old chain.

Where a chain came from is recorded on each spawned decision task, so oversight can answer "how was this routed?" without re-deriving it.

Formalisation therefore means submit for approval, not publish. The role is created in an in-approval stage and the access policy that assigns it is created disabled. Only when the chain completes does the role become active and the policy switch on. Steps scoped per entitlement fan out into one task per proposed permission, and a permission rejected at that step is removed from the role before it activates — so the thing that goes live is what the reviewers actually agreed to, not what was proposed.

Runs you start, and the run that runs itself

Alongside runs an administrator starts — optionally narrowed to one scope preset, or to a single connected system — a background sweep runs every twelve hours to keep the ungoverned-access analysis fresh, so that surface can show a real answer instead of a confident zero.

Because both write proposals, superseding is bucketed. The background sweep and user-facing runs form two separate buckets, and a run only supersedes pending proposals from its own. Without that, a compliance sweep firing overnight would mark as superseded the proposal someone had spent the afternoon reviewing — silently, with no decision recorded anywhere. Within a bucket, a new run does supersede the pending remainder, because a fresh run is meant to be a fresh slate; that behaviour can be switched off per run, and accepted or rejected proposals are never touched.

Proposals describing the same cohort are merged across strategies before they are written, on matching cohort attributes plus member overlap, with a stricter overlap threshold the weaker the attribute match. Two rules finding the same team should produce one opportunity, not two.

Superseded is a fourth outcome, not a decision. It means a newer run replaced this proposal. It is not a rejection, not an approval in flight, and a superseded proposal never became a role.

Decommission is a lifecycle, not a delete

Two governance events retire a role: a role certification whose reviewers reject it, where the rule's action is to disable the role, and an administrator deliberately offboarding it. Both do the same thing — create a deprecation plan, approve it, and move it to deprecated with a real sunset date of now plus a grace window, tenant-configurable and thirty days by default.

During the window the role is blocked from new requests but holders keep their access. Nothing is deleted. When the deadline passes, the sunset sweep revokes every holder's grant through the normal provisioning path — so the change reaches the target system rather than only the database — writes a per-grant audit entry answering "why was this revoked", and moves the role to retired. A plan that fails is collected and reported rather than aborting the sweep for everything else.

Cancelling before sunset restores the role to the stage it actually held when it was scheduled, captured at that moment: a role that was under review returns to under review, a draft returns to a draft. An earlier version reset everything to active, which quietly promoted a draft role into a live one on the way back.

Three other places set a "stop granting this" flag on a role — sync drift detection, and the advisers that notice a role with no holders or a dangling organisational reference. Those block new requests and nothing else: no plan, no deadline, no revocation. They are signals, and they are deliberately not this lifecycle.

Known edges, published rather than discovered

Further reading: