> 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/administration-guide/identities/grant-and-revoke-access.md). # Grant and revoke access Grant or revoke a role, group, resource or organization on a user from the Webconsole, and prove the change reached the managed system. ## What this is, and when you need it Granting access writes a membership between the user and a role, group, resource or organization, and — on shipped configuration — provisions that change to every managed system the entitlement reaches. Use this for a one-off grant to one person; use a role or a business rule when the same access should follow a population. Two things about this task surprise people, and both are covered below: the audit action depends on which screen you used, and an end date does nothing on its own. ## At a glance | | | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | | **You will end up with** | A membership on the user, and the matching account or group membership in the target | | **Where** | The entitlement tabs on a user's record: **Member of Roles**, **Member of Groups**, **Entitled to Resources**, **Member of Organizations** | | **You need first** | The `USER_ENTITLEMENTS_PAGE` grant plus the specific tab's grant, and the entitlement you intend to grant | | **Takes** | A minute to save; provisioning to the managed systems is asynchronous | | **Reversible** | Yes — revoke, then confirm the target. Accounts already created in a target may survive the revocation | ## Grant or revoke the entitlement {% stepper %} {% step %} ### Open the user's entitlement tab Open the user, then the tab for the kind of access you are granting. The four tabs are separate menu items with separate grants: | Tab | Menu resource | | ----------------------- | ------------------------ | | Member of Roles | `USER_ROLES_MEMBERSHIP` | | Member of Groups | `USER_GROUPS_MEMBERSHIP` | | Entitled to Resources | `USER_RES_MEMBERSHIP` | | Member of Organizations | `USER_ORG_MEMBERSHIP` | A missing tab is a missing grant on that resource, or on their parent `USER_ENTITLEMENTS_PAGE`. {% endstep %} {% step %} ### Add or remove the entitlement, with its rights and dates Alongside the entitlement itself you can set access rights, a start date and an end date. All three are properties of the **membership**, not of the user. {% endstep %} {% step %} ### If you set an end date, confirm something will act on it {% hint style="danger" %} **An end-dated grant is still a live grant until something acts on the end date.** The batch task that acts on it is `AUTO_REVOCATION` — name "Notification of expiring/revoke of expired access", cron `0 0 20 * * ?` — and it ships **disabled**. On a shipped configuration, end-dating access records an intention and revokes nothing, indefinitely, with no error and no audit event to say so. Confirm at **Administration → Batch Tasks** that the `AUTO_REVOCATION` row's **Enabled** column reads `Y` before you rely on end dating. See [Shipped batch tasks](/administration-guide/reference/shipped-batch-tasks.md). {% endhint %} {% endstep %} {% step %} ### Save, and note which audit action you just produced Saving a single entitlement records that entitlement's own action — `ADD_USER_TO_ROLE`, `ADD_USER_TO_GROUP`, and so on. Saving the whole set from a save-everything screen records `MODIFY_USER` instead, described "Save user with entitlements". Which one you get depends on the screen, not on what you granted. {% endstep %} {% endstepper %} ## Verification | What you did | Evidence | | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | Granted a role, group, resource or organization | The matching `ADD_USER_TO_*` audit action, then the membership on the user's entitlement tab, then the account or group membership in the target | | Revoked one | The matching `DELETE_USER_FROM_*` action, then the membership's absence, then the target | | End-dated a grant | The end date stored on the membership — **and** whether `AUTO_REVOCATION` is enabled, because otherwise nothing will act on it | | Expected the target to change | A `PROVISIONING_MODIFY` child event under the grant event. Its absence means no connector was asked to do anything | {% hint style="info" %} **To monitor privileged-role assignment, alert on three actions, not one.** `ADD_USER_TO_ROLE` catches the single-grant screens, `MODIFY_USER` catches the bulk entitlement save, and `PROVISIONING_MODIFY` catches what actually reached the managed system. Each covers a case the other two do not, and only the third tells you an account was really changed. A monitor built on `ADD_USER_TO_ROLE` alone misses every grant made through a save-the-whole-set screen. See [Audit actions and retention](/administration-guide/reference/audit-actions-and-retention.md). {% endhint %} Whether a grant provisions at all is one property, and it governs every screen: `org.openiam.provision.service.user.entitlements.flag`, label **Is Entitlements via Provisioning Active?**, ships `true`. Set it `false` and the membership is written with no provisioning and no `PROVISIONING_MODIFY` — an audit trail that shows the grant and nothing about the managed system, which reads exactly like a connector that succeeded. ## When it goes wrong | Symptom | Cause | Fix | | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | An entitlement tab is missing on the user record | No grant on `USER_ENTITLEMENTS_PAGE` or on the specific tab's menu resource | Grant the resource ID from the table above | | The grant saved but the target is unchanged | The managed system's resource is not reached by this entitlement, or provisioning is disabled for that managed system | Check the resource-to-managed-system relationship, then the managed system's provisioning setting | | A grant is audited but no `PROVISIONING_MODIFY` follows | `org.openiam.provision.service.user.entitlements.flag` is `false`, so the membership is written without provisioning | Set it back to the shipped `true` | | A role grant produces no `ADD_USER_TO_ROLE` event | The screen saved the whole entitlement set, which audits `MODIFY_USER` described "Save user with entitlements" | Monitor `ADD_USER_TO_ROLE`, `MODIFY_USER` and `PROVISIONING_MODIFY` together | | End-dated access still works past the end date | `AUTO_REVOCATION` ships disabled | Enable the batch task | | Access you granted disappeared after a termination | Terminate and deceased end-date role and group memberships, and remove them when `org.openiam.workflow.termination.access.remove` is `true` | See [Run a user lifecycle action](/administration-guide/identities/user-lifecycle-actions.md) | ## What a save-everything screen replaces Saving one entitlement from its own tab records that entitlement's own audit action and touches nothing else. Saving from a screen that submits the whole user — the classic user form — records `MODIFY_USER`, described "Save user with entitlements", and submits the entitlement lists *as shown on that form*. That distinction matters because those lists are only on the form when the user's page template puts them there. Three built-in template fields do it: | Template field | Name as it appears in the page template editor | Puts on the form | | ------------------------- | ---------------------------------------------- | ------------------------------------ | | `USER_SHOW_ROLES` | User can select a Role | The user's roles | | `USER_SHOW_GROUPS` | User can select a Group | The user's groups | | `USER_SHOW_ORGANIZATIONS` | User can define his organizational structure | The user's organization affiliations | {% hint style="danger" %} **On a form that shows an entitlement list, saving the user replaces that list.** An entry the operator removed from the list is marked for deletion, not merely left out of the save. Somebody tidying a long organization list on the way to correcting a phone number will revoke affiliations, and the save reports success. Prefer the entitlement tabs, which change one membership at a time and audit it under its own action. If your operators do use the classic form, either leave these three template fields off the template for the people they administer, or teach them that the list on that form is the complete set. See [Build a page template](/administration-guide/identities/page-templates-and-custom-fields.md). {% endhint %} ## Compare two users' access When you are asked "why can she do this and he cannot", the answer is a comparison rather than two separate reads. `/webconsole/compare-users` puts two users' roles, groups, resources and organizations side by side. Use it before you grant anything: copying an entitlement set you have not diffed is how one person's over-provisioning becomes two people's. ## Roll it back Revoke the entitlement, then confirm the target. What does not reverse is anything the grant caused a connector to create: an account provisioned by a role grant is not necessarily deleted when the role is revoked — that depends on the managed system's deprovisioning configuration. ## Related * [Manage related accounts](/administration-guide/identities/related-accounts.md) — for a second account belonging to the same person * [Run a user lifecycle action](/administration-guide/identities/user-lifecycle-actions.md) — the actions that end-date or remove the memberships granted here * [Audit actions and retention](/administration-guide/reference/audit-actions-and-retention.md) — every audit constant named on this page *Applies to OpenIAM 2026.8.1. Last reviewed 7 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/administration-guide/identities/grant-and-revoke-access.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.