> 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/start/object-model.md). # The OpenIAM object model The objects OpenIAM administration is made of — users, identities, resources, roles, groups, organizations, entitlements, managed systems, content providers, policies and metadata — each anchored to t ## What this is, and when you need it Every other page in this guide names these objects. This page defines them once and anchors each to the screen you manage it on and the table it lives in, so that when a screen behaves unexpectedly you can trace the object rather than guess at it. The table names are here for the break-glass queries in [Change configuration safely](/administration-guide/start/change-safely.md) and in the pages that follow; nothing on this page asks you to write to them. Read the [resource type table](#the-resource-type-table) even if you skim the rest. It is the single most useful orientation table in OpenIAM: it tells you which console screens are backed by a resource, which are hierarchical, which are searchable, and therefore which ones can be granted, approved, certified and audited like any other entitlement. ## People: users, identities and logins **A user is a person or a service principal**, held in `USERS`. A user has exactly one row, one status — 21 values, offered on the **Status** field and listed under [User statuses](/administration-guide/reference/enums.md#user-statuses) — and one user type, which is a metadata type in the `USER_OBJECT_TYPE` grouping. **An identity is a credential on a managed system.** `LOGIN`, keyed by the login name together with the managed system it belongs to, so the same login name on two managed systems is two identities. One user normally has several: the OpenIAM identity on the default managed system, plus one per connected application. This distinction is the thing new administrators most often collapse, and it matters constantly: * Provisioning creates and destroys *identities*, not users. Deactivating a user issues one deprovisioning request per identity, and each can succeed or fail on its own. * An account discovered on a managed system with no matching identity is an **orphan** — see [Grant and revoke access](/administration-guide/identities/grant-and-revoke-access.md). * An identity can exist without OpenIAM having created it, and OpenIAM can hold an identity for a system it cannot currently reach. **Attributes** live in `USER_ATTRIBUTES` as name/value rows, not as columns. This is why "add a field to the user" is a page-template and metadata-element exercise rather than a schema change — see [Build a page template](/administration-guide/identities/page-templates-and-custom-fields.md). It is also how delegated administration is stored: the delegation filters are user attributes named `DLG_FLT_*`. ## Resources: the one abstraction underneath everything `RES`. A resource is OpenIAM's universal protected-thing. Applications, managed systems, menu items, URI patterns, authentication providers, reports and page templates are all resources, differentiated only by `RESOURCE_TYPE_ID`. The payoff is uniformity. Anything that is a resource can be granted to a user, role or group; can be owned and administered through an association; can carry a risk level; can be certified in a campaign; and produces audit events with the same shape. The cost is that "resource" in the Webconsole means something much broader than "application", and you have to read the type to know what you are looking at. Resource-to-resource composition lives in `res_to_res_membership`. That is how a menu page contains its buttons: `USER_INFO_PAGE` is a resource whose members are `RESET_ACCOUNT`, `DEACTIVATE_USER`, `TERMINATE_USER` and the rest. ### The resource type table `RESOURCE_TYPE` holds nineteen rows on a current release. Confirm the list on your own deployment at **Access Control → Resource Type** (`/webconsole/resourceTypes`), and each row's flags at `/webconsole/editResourceType`. `Hier.` is `SUPPORTS_HIERARCHY` — whether instances can contain one another; `Search.` is `SEARCHABLE` — whether instances appear in the generic resource search. | `RESOURCE_TYPE_ID` | Shipped `DESCRIPTION` | Hier. | Search. | What it is for | | ---------------------- | ------------------------- | ----- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | `MANAGED_SYS` | Managed Systems | Y | — | A connected external system. The resource is what you grant to give someone an account there | | `MAN_MANAGED_SYS` | Manual Managed Systems | Y | Y | A target with no connector; fulfilment is a human task. See [Manual fulfilment](/administration-guide/requests/fulfilment.md) | | `MENU_ITEM` | Menus | Y | N | A console navigation node or action button. Explicitly `SEARCHABLE='N'` so menus do not pollute resource search | | `CONTENT_PROVIDER` | Content Provider | Y | — | A protected host and application namespace, with its auth cookie and authentication policy | | `URL_PATTERN` | Url Pattern | Y | — | A path within a content provider, with its own authentication level and XSS rules | | `URI_PATTERN_METHOD` | URI Pattern Method | Y | — | A single HTTP method on a URI pattern, so `GET` and `POST` on one path can be protected differently | | `AUTH_PROVIDER` | Authentication Provider | Y | — | A configured authentication mechanism | | `AUTH_REPO` | Authentication Repository | Y | — | The credential store an authentication provider authenticates against | | `UI_TEMPLATE` | UI Template | Y | — | A page template. `NEW_USER_TEMPLATE` is one of these | | `UI_WIDGET` | UI Widget | Y | — | An individually entitleable component inside a page | | `SYS_ACTION` | System Action | Y | — | A named product operation used as an authorization target | | `ADMIN_RESOURCE` | Admin Resource | **N** | — | Administrative scope over another object. The only shipped type with hierarchy explicitly switched off | | `REPORT` | Report | N | Y | A report definition. See [Shipped reports](/administration-guide/reference/shipped-reports.md) | | `WORKFLOW` | Protects Workflows | Y | — | An Activiti process definition as an authorization target. See [Shipped approval workflows](/administration-guide/reference/shipped-workflows.md) | | `ACTIVITI_REQUEST` | Activiti Requests | Y | Y | A request type, so approver associations can be attached per request kind | | `OAUTH_SCOPE` | OAuth Scope | N | Y | An OAuth 2.0 scope, granted like any entitlement. See [OAuth 2.0 and OpenID Connect](/administration-guide/federation/oauth-and-oidc.md) | | `APPLICATION_CATEGORY` | Application category | Y | Y | A grouping for the SelfService application launcher | | `PROFILE` | Access Profiles | Y | Y | A bundle of entitlements granted as one unit | | `SOD_ENTITLEMENT` | SoD Entitlement | N | Y | Auto-created when a segregation-of-duties rule set is activated | Three notes on that table that save real time: **`SUPPORTS_HIERARCHY` was set globally in 3.1.0.0.** That release turned it on for every resource type at once and then switched only `ADMIN_RESOURCE` back off. Types that already existed therefore inherit `Y` whether or not hierarchy means anything for them; types added since 3.1.0.0 state their own value. Read the flag on the type rather than reasoning about it: open the type at `/webconsole/editResourceType`. **`SOD_ENTITLEMENT` is in the database but not in the product's built-in list of resource types.** The row ships as of 2026.7.1.0, and the compiled-in enumeration lists eighteen values without it. The resource type used for auto-created SoD entitlement resources is configurable through `org.openiam.sod.ruleset.resource.type`, whose default of `SOD_ENTITLEMENT` is compiled in rather than seeded, so the property has no `PROPERTY_FILE_VALUES` row and will not appear on the System configuration screen. **This one cannot be confirmed from the console at all** — neither the property nor its value is displayed anywhere. If you need it changed, it is a deployment-owner change to the service properties, not a Webconsole edit. **`ADMIN_RESOURCE_ID` columns no longer exist.** 3.1.0.0 added `ADMIN_RESOURCE_ID` to `RES`, `ROLE`, `GRP` and `COMPANY`; 4.0.0.0 dropped all four. The `ADMIN_RESOURCE` type row survives, but administrative scope in the current product is expressed through association types and delegation filters, not through that column. If you are following older documentation that tells you to set an admin resource on a role, it is describing a schema that has been gone since 4.0. Resource type display names are localized through `LANGUAGE_MAPPING` rows with `REFERENCE_TYPE = 'ResourceTypeEntity.displayNameMap'`, so the label you see in the console may not match the `DESCRIPTION` column. When they disagree, the `LANGUAGE_MAPPING` row wins. ## Roles, groups and organizations: three collections, three purposes They look interchangeable on screen and are not. | | Role | Group | Organization | | ---------------------- | ------------------------------------ | -------------------------------------- | ------------------------------------------ | | Table | `ROLE` | `GRP` | `COMPANY` | | Membership table | `USER_ROLE` | `USER_GRP` | `USER_AFFILIATION` | | Type metadata grouping | `ROLE_TYPE` | `GROUP_TYPE` | `ORG_TYPE` | | Normally means | *what this person is entitled to do* | *a directory object to be provisioned* | *where in the enterprise this person sits* | **Roles** carry entitlements. A role bundles resources and other roles, and a role grant is the usual unit of access request, approval and certification. **Groups** most often correspond to a real group object in a target directory. Because a group is a first-class OpenIAM object with its own page template (`DEFAULT_GRP_TEMPLATE`) and classification metadata, it can be requested and provisioned as an object rather than only as a membership. **Organizations** are structure, not access. The affiliation table is named `USER_AFFILIATION`, not `USER_ORG`, which is a reliable clue: an organization membership is an affiliation with a type, and `org.openiam.affiliation.primary.type.id` (shipped `100`) names the primary one. Organizations are also the axis several scoping features work along, including `org.openiam.selfservice.organization.search.enabled` and tenant filtering by organization. Composition is by membership row throughout — resource inside resource, group inside group, organization inside organization, resource attached to organization. Every one of those rows carries an operation, a start date and an end date, which is what makes end-dated access and the `AUTO_REVOCATION` batch task possible. You can see the dates on the grant itself: open the user's **Roles**, **Groups** or **Resources** tab and the **Start Date** and **End Date** on a membership are the same values. ## Entitlements An entitlement is a membership row that connects a user to a role, group, resource or organization, with rights, a description and an optional date range. There is no separate entitlement table — the membership xref *is* the entitlement. You grant and revoke them from the user's own entitlement screens, and each operation has its own audit action: `ADD_USER_TO_RESOURCE`, `DELETE_USER_FROM_RESOURCE`, `ADD_USER_TO_GROUP`, `DELETE_USER_FROM_GROUP`, `ADD_USER_TO_ROLE`, `DELETE_USER_FROM_ROLE`, `ADD_USER_TO_ORGANIZATION`. See [Grant and revoke access](/administration-guide/identities/grant-and-revoke-access.md). Who may administer an entitlement is expressed as an **association type**, 15 values: `USER`, `SUPERVISOR`, `ROLE`, `GROUP`, `TARGET_USER`, `RESOURCE`, `ORGANIZATION`, `OWNER`, `ADMIN`, `APPLICATION_OWNER`, `APPLICATION_ADMIN`, `ENTITLEMENT_OWNER`, `ENTITLEMENT_ADMIN`, `SERVICE_ACCOUNT_OWNER`, `CERTIFICATION`. The same list drives approver associations — see [Approver association types](/administration-guide/reference/enums.md#approver-association-types). ## Managed systems `MANAGED_SYS`, and simultaneously a resource of type `MANAGED_SYS`. A managed system is one connected system: its connector, its connection parameters, its policy map, its reconciliation configuration, and the resource you grant to give somebody an account on it. Two facts about managed systems belong in the object model rather than in a procedure: * **The resource and the managed system are one object seen twice.** Granting the resource is what entitles a user to an account. This is why an entitlement grant can provision, and why revoking one can deprovision. * **Manual managed systems are a different resource type.** `MAN_MANAGED_SYS` exists so that managed systems with no connector still participate in requests, approvals and certification, with a human closing the loop. Identities on a managed system are `LOGIN` rows carrying that managed system's id. Attribute translation between OpenIAM and the managed system is the policy map — see [Policy map](/administration-guide/lifecycle/policy-map.md). ## Content providers and URI patterns This pair decides what is reachable and what is protected, and it is the part of the model where a mistake locks people out. **A content provider** (`CONTENT_PROVIDER`) is a protected host plus an application namespace. The shipped `DEFAULT_CP` row carries `DOMAIN_PATTERN`, `IS_SSL`, `AUTH_COOKIE_DOMAIN` and `AUTH_COOKIE_NAME`, and its resource `URL` is built as `http:///selfservice`. **A URI pattern** (`URI_PATTERN`) is a path inside a content provider, with a `PARAM_MATCH_MODE` and its own authentication requirement. The set that ships with `DEFAULT_CP` is worth reading once, because it shows the mechanism plainly. See them for yourself on the content provider at `/webconsole/contentProviders`, under **URI Patterns**: | `URI_PATTERN_ID` | `PATTERN` | Auth level grouping | | ------------------------- | --------------------------------------- | -------------------------------- | | `DEF_CP_SELSERVICE_SLASH` | `/selfservice/*` | (inherits the provider's policy) | | `DEF_CP_WEBCONSOLE_SLASH` | `/webconsole/*` | (inherits the provider's policy) | | `SELFREG_PATTERN` | `/selfservice/selfRegistration.html` | `NONE` | | `LOGIN_HTML` | `/idp/login.html` | `NONE` | | `LOGOUT_PATTERN` | `/idp/logout.html` | `NONE` | | `UI_STATIC` | `/openiam-ui-static/*` | `NONE` | | `UNLOCK_USER_RESET_FORM` | `/idp/unlockUserResetPasswordForm.html` | `PASSWORD_AUTH` | `URI_AUTH_LEVEL_GRP_XREF` binds a pattern to an authentication level grouping; `NONE` means public. `URI_PARAM_XSS_RULES` exempts named parameters from XSS filtering — which is why `password`, `currentPassword`, `newPassword` and `newPasswordConfirm` are listed explicitly, since XSS filtering would otherwise mangle them. Two further xrefs matter downstream. `URI_PATTERN_METHOD` and `URI_PATTERN_METHOD_XREF` let you protect individual HTTP methods; each per-method row is a resource of type `URI_PATTERN_METHOD`, and that type is fixed rather than configurable. And `METADATA_URI_XREF` binds a **page template** to a URI pattern — the mechanism, and the trap, described in [Self-registration](/administration-guide/identities/self-registration.md). {% hint style="danger" %} Content providers and URI patterns are the objects whose misconfiguration cannot be repaired from the Webconsole, because they decide whether the Webconsole is reachable. Establish and test a break-glass administrator before you touch them — see [Change configuration safely](/administration-guide/start/change-safely.md). {% endhint %} ## Policies `POLICY`, with rules stored as `POLICY_ATTRIBUTE` rows rather than columns. Password composition, authentication behaviour and IT policy are all policies. A policy is not a property: it has its own screens, its own export unit and its own rollback story. The parameter names and the values the shipped default policy enforces are in [Password and authentication policy parameters](/administration-guide/reference/policy-parameters.md). ## Metadata types and elements This is the extension system, and it is worth understanding because so many drop-downs are backed by it. **A metadata type** (`METADATA_TYPE`) is one enumerated value with a `GROUPING` that says what it enumerates. There are 42 groupings, and only some of them are administrable from the metadata screens — a grouping you cannot find there is one the product manages itself. Examples you will meet in the identities section: | Grouping | Enumerates | Shipped members you will see | | ---------------------------------- | ----------------------------------------- | ------------------------------------------------------------------------------------------ | | `USER_OBJECT_TYPE` | User types | The types offered on the select-user-type step | | `USER` | Secondary user status values | `DECEASED`, `LEAVE_WITH_PAY`, `LEAVE_OF_ABSENCE`, `PENDING_DEACTIVATION`, `PENDING_DELETE` | | `PAGE_TEMPLATE_TYPE` | Page template kinds | `USER_PAGE_TEMPLATE_TYPE`, `GROUP_PAGE_TEMPLATE_TYPE`, `ROLE_PAGE_TEMPLATE_TYPE` | | `RELATED_ACCOUNT_ASSOCIATION_TYPE` | Related-account relationships | `AD_DEV_ACCOUNT`, `AD_STAGE_ACCOUNT`, `PRIVILEGED_ACCOUNT` | | `PHONE`, `EMAIL`, `ADDRESS` | Contact sub-types | `PRIMARY_EMAIL` and friends | | `SUPERVISOR_TYPE` | Kinds of supervisory relationship | — | | `JOB_CODE`, `AFFILIATIONS`, `RISK` | Job codes, affiliation types, risk levels | — | The full list is at [Metadata type groupings](/administration-guide/reference/enums.md#metadata-type-groupings). **A metadata element** (`METADATA_ELEMENT`) is a *field* rather than a value — a custom user attribute with a type, valid values and validation. Elements are attached to page templates through `METADATA_ELEMENT_PAGE_TEMPLATE` and its xrefs. See [Build a page template](/administration-guide/identities/page-templates-and-custom-fields.md). {% hint style="info" %} Metadata types are localized through `LANGUAGE_MAPPING` with `REFERENCE_TYPE = 'MetadataTypeEntity.displayNameMap'`. Several shipped rows have an English `TEXT_VALUE` identical to the `TYPE_ID` — `LEAVE_WITH_PAY`'s English display name is literally `LEAVE_WITH_PAY` — so a screaming-snake-case label in the UI is a missing translation, not a bug. See [Languages and localization reference](/administration-guide/reference/languages.md). {% endhint %} ## Search indexes Several screens do not read the relational tables at all. User search, orphan management and SoD violations are served from OpenSearch indexes: `users`, `userattributes`, `orphan`, `user-recalculation`, `user-violated-sod-policy` and `incomplete-self-registration-user` among 32 in total. Orphans in particular have **no database table at all** — an orphan exists only in the `orphan` index, which is why there is nothing to query for one under break-glass and why a lost index means lost orphan records rather than a stale screen. That is why "the record is in the database but not on the screen" is a real and common condition, and why the fix is a reindex rather than a data correction. See [Search indexes and the authorization graph](/administration-guide/reference/search-indexes.md). ## Related * [Where settings live](/administration-guide/start/where-settings-live.md) — which of these objects are properties and which are not * [Reference](/administration-guide/reference.md) — the enumerated values behind every drop-down named here * [Manage identities](/administration-guide/identities.md) — the objects on this page, put to work *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/start/object-model.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.