> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/solution-architecture/governance/how-access-is-granted.md). # How access gets granted The four ways access reaches a person in OpenIAM — birthright, role-derived, rule-driven and requested — what each costs to design and to run, the two scheduled jobs that decide whether the design is ## What this is, and when you need it Once the catalogue exists, every entitlement in it needs an answer to one question: **what decides who holds this, and what decides when they stop?** OpenIAM supports four defensible answers and will let you use all four on the same entitlement, which is exactly the failure this page exists to prevent. The decision is per entitlement, not per programme. A design that says "we will automate access" without saying which mechanism owns which role has not made the decision; it has deferred it to whoever configures each role, and they will make it differently each time. You need this page when you are writing the access-management design, when you are estimating how much of the estate can realistically be automated, and when someone senior asks what proportion of access will be granted without a human in the loop. That last question has a real answer, and it is measurable after go-live. ## The decision | Mechanism | What decides the population | What it costs | What it buys | | ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Birthright** — universally assigned roles, groups or managed systems | Nothing. Everybody active gets it | No conditions and therefore no exceptions: a universal assignment is re-asserted on every save, so removing it from one person by hand does not last. Turning it off later removes nothing already granted | The cheapest possible mechanism for genuinely universal access — mail, the intranet, the base directory account | | **Role-derived** | Membership of a role, which then carries whatever it contains | The design work in Part 4's first page: a catalogue with owners, and discipline about depth | One decision grants a coherent bundle, and one review revokes it. This is what makes certification tractable | | **Rule-driven** — a business rule over governed identity data | A condition tree over user attributes, with a paired action for match and no-match | The deciding attribute has to be governed, present on every record, and correct. Getting that wrong grants or revokes at population scale, quietly | Access follows the person: a transfer or a status change moves entitlements without anyone raising a ticket. It is the only mechanism that removes access as automatically as it grants it | | **Requested** — a request with an approval flow | A named human, on the record | Latency, and an approver population who must actually decide rather than approve. Every request is an event somebody has to work | A defensible decision with a name and a date attached, for access that genuinely requires judgement | Two further paths exist and should be named so they are not mistaken for one of the four. **Synchronization from an authoritative source** grants access because a feed said so, which makes the feed the governing system for that entitlement — a legitimate design, but it moves the governance question outside OpenIAM. **A direct grant by an administrator** is the exception path, and it should look like one: an end date and a recorded reason, not a habit. ## How the rule mechanism actually works Rule-driven access is the one most often designed on assumption, so it is worth stating what the product does. {% hint style="info" %} **A rule-driven grant is not the same thing as policy-based access control.** A rule changes what a person holds, and what they hold is then visible to certification and to segregation of duties. A policy decides one request and grants nothing — see [Deciding access at request time](https://github.com/openiam-platform/gitbook-docs/tree/main/solution-architecture/governance/request-time-policy.md). {% endhint %} A rule is a condition tree over the user record — attributes combined with and, or, negation, and optionally a script where the tree cannot express the policy — plus **two** action sets: one that runs when the condition is true and one that runs when it is false. The no-match set is the removal event, and a rule with no no-match set grants forever. Three properties of that design decide how you can use it. **Conditions test governed identity data, and several of the useful attributes are identifiers rather than the labels you see on screen.** A condition on a job code, an organization affiliation, a role or a user subtype compares stored identifiers, not names. This is a data-quality dependency rather than a configuration detail: if the feed does not carry the value, or carries it inconsistently across populations, the rule is silently wrong for the populations it does not fit. **A condition that cannot be evaluated resolves to false, and false runs the removal set.** That is the single most consequential behaviour in the mechanism. A rule does not fail safe: an attribute the engine cannot read, or an operator the attribute does not support, produces a no-match, and a no-match with a removal action removes access from everybody. Design rules whose conditions cannot fail, and treat any rule change as a population-scale change. **Removal targets the entitlement, not the grant.** The no-match action removes the named role or group from the user regardless of how that membership came to exist. So a rule that owns a role owns it completely — a request-approved grant of the same role will be taken away at the next evaluation. This is the mechanism behind "my change was reverted", and it is the reason the one-mechanism rule below is not advice but a constraint. One capability is worth designing around because most people never find it: **a rule can raise an access request instead of granting directly.** The rule identifies who probably needs the access; the approval flow decides. That is the right shape for privileged access driven by an attribute — automation for the identification, a human for the decision — and it avoids the usual binary between silent automation and a wholly manual process. ## The two scheduled jobs that decide whether your design is real Two shipped batch tasks turn design intent into behaviour, and **both ship disabled**. A design that assumes either one is running will not do what its author believes. | Shipped task | What it does | State as shipped | What the design must decide | | ------------------------------ | ----------------------------------------------------------------------------- | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | Business-rule recalculation | Re-evaluates rules across the whole population and provisions the differences | **Disabled**, seeded to run daily at midnight | Who turns it on, and what the review step before a run looks like. Until it runs, a saved rule reaches only users who are created or changed | | Revocation of end-dated access | Acts on memberships whose end date has passed | **Disabled**, seeded to run daily | Whether time-bound access is a real control or a recorded intention. Until it runs, an end date is a note in a row that nothing enforces | Take the second one seriously, because it silently undermines a common design. Membership end dates are available everywhere, and "we will grant this for ninety days" is a normal thing to write in a design document. As shipped, nothing acts on that date. The access remains, the review shows it as current, and the only thing that expired was the intention. Either enable the task, deliberately and with a tested notification path, or revoke through a rule or a campaign and say so — but do not put an unenforced end date in a control description. The first has a subtler consequence. Because there is no scheduled sweep by default, a rule's authority over its population is partial: new and modified users get the rule's answer, everybody else keeps whatever they had. That is not a bug to route around; it is a decision about who owns a population-scale change and when it happens. Decide it in the design, name the owner, and treat each sweep as a change with a review before it and evidence after it. ## One authoritative mechanism per entitlement This is the rule the whole page reduces to. > **For any given role, group or resource, exactly one mechanism decides who holds it.** The others may observe; none of them may also grant. Encoding the same policy in a business rule *and* a synchronization *and* an administrator's routine is the single most common cause of unexplained access changes, and it is invisible to everyone until the first collision. It is also invisible to an audit, because each individual change looks correct. The practical form of this rule is a column in the catalogue: for every entitlement, the mechanism that owns it and the person accountable for that mechanism. Load it with the catalogue, keep it in the same file, and treat a request to add a second path as a change to the design rather than a configuration task. ## The mix most organizations end up with There is no target ratio worth quoting as a benchmark, but the shape is consistent enough to plan against, and it is a useful sanity check on an early design. A small number of **birthright** entitlements cover everybody — the directory account, mail, collaboration tools, the intranet. This is a handful of objects and a large fraction of all memberships. The **role-derived** layer covers job-shaped access wherever the organization has stable jobs: shift workers, branch staff, clinical roles, plant operations. Where the job structure is stable this is the largest governed layer and the one certification is built on. Where it is not — research, project work, short contractor engagements — it stays small no matter how much design effort is spent on it, which is a Part 4 conclusion better reached early than late. The **rule-driven** layer is narrow by count and wide by impact: a handful of rules keyed on employment type, location, cost centre or organizational unit, each owning one entitlement completely. Its value is in the mover and leaver cases rather than the joiner, and its risk is proportional to the quality of the attribute it keys on. The **requested** layer takes everything that requires judgement: elevated access, cross-functional access, anything with a licence cost, anything an application owner insists on approving. It is the layer sponsors most want to shrink and the one that should shrink last, because it is the only mechanism that produces a named decision. The failure mode to plan against is not the mix being wrong. It is a fifth layer nobody designed: administrators granting access directly because one of the four was too slow. That layer does not appear in a design document and always appears in the data. ## Measuring it after go-live Every membership records how it came to exist — an approved request, an administrator, a business rule, a system assignment, or a fulfilment still pending. That tag is the measurement your governance programme runs on, and it is the honest answer to "is access governed here?". Two readings are worth building into the operating rhythm. **The share of memberships created by administrators by hand** is the size of the ungoverned layer, and a large share means the governed paths are being bypassed whatever the process says. **The share created by rules and by approved requests** is the automation you actually achieved, as opposed to the automation the design proposed. Both are available without asking anybody, which is what makes them useful. ## What we recommend **Assign the mechanism per entitlement, in the catalogue file, at design time.** Not per programme, not per application, and not at configuration time. **Use birthright only for access that is genuinely universal.** The moment somebody asks for an exception, universal assignment is the wrong mechanism — it has no exception path, and every user save re-asserts it. **Make rules narrow and their conditions unfailable.** One rule, one entitlement, a condition on a governed attribute, and a no-match action you have deliberately chosen. Review the population a rule matches before it goes live, and again after the first sweep. **Use a rule to identify and an approval to decide, for anything sensitive.** It is the best-shaped option the product offers and the least used. **Decide explicitly what happens to the two disabled tasks**, and write the decision into the design rather than leaving it to installation. An end date nothing enforces is worse than no end date, because it reads like a control. **Instrument the mix from the first month.** The membership tags make ungoverned granting visible early, while it is still a habit rather than an operating model. The circumstance that changes all of this is an estate where the identity data is not yet trustworthy. Rule-driven access built on an attribute that is only right for two thirds of the population will do more damage than manual granting, because it does it at scale and overnight. Where Part 2's decisions are still settling, weight the design towards role-derived and requested access, and add rules as each attribute earns its trust. ## What OpenIAM does not do here * **The population-wide business-rule recalculation ships disabled.** Until it is enabled or run deliberately, a rule reaches only users who are created or modified. * **End dates on memberships do not enforce themselves.** The task that acts on them ships disabled. * **Universal assignment has no per-user exception.** Removing a universally assigned entitlement from one person lasts until that person's next save; turning the flag off removes nothing already granted. * **A rule's removal action is not restricted to what the rule granted.** It removes the named entitlement however it was acquired. * **A rule condition that cannot be evaluated resolves to false**, which runs the no-match action. There is no safe-mode fallback. * **There is no simulation of a rule against the whole population that shows the resulting provisioning.** You can review which users a rule matches; what each target system would receive is a separate question answered by managed-system simulation. ## Related * [Designing the role model](/solution-architecture/governance/role-model.md) — the catalogue this page assigns mechanisms to. * [Designing a certification programme](/solution-architecture/governance/certification-programme.md) — where the mechanism mix becomes evidence. * [Deciding access at request time](https://github.com/openiam-platform/gitbook-docs/tree/main/solution-architecture/governance/request-time-policy.md) — the conditions no membership can express, and why a policy is not a fifth mechanism. * *Build a business rule*, *Grant birthright access* and *Membership tags* in the Administration Guide — the mechanisms, configured. * Part 2, *Choosing your authoritative sources* — whether the attribute a rule keys on is governed at all. *Applies to OpenIAM 2026.8.1. Last reviewed 28 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/solution-architecture/governance/how-access-is-granted.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.