# Access control **Access Control** in OpenIAM is a core service that lets you: * Determine which accounts and entitlements each user should have in an application. With business rules, it can also assign birthright access. * Control what users can do in the OpenIAM interface. This includes module access and field visibility. * Control which applications a user can access through SSO. * Provide an API for authorization in other applications. Like the Authentication service, **Access Control** — also called **Authorization Manager** — is an essential platform service. ## Overview The Access Control service in OpenIAM is based on a flexible Role-Based Access Control (RBAC) model. The RBAC model supports: * Inheritance. * Permissions. * Creation of new entitlement types. * Entitlement owners and admins. * Workflow-based approval model. * Access for a limited period. The OpenIAM RBAC model consists of four primary entitlement objects. Using these objects, you can define a custom model that matches business requirements and reflects your application landscape. * **Roles** - can be categorized as **Business Roles** and **Technical Roles**. * **Business Roles** are usually associated with a person’s job. They can grant access to a collection of applications or functions needed to perform that job. For example, an admin in the DBA team may be a member of the *Database Administrator (DBA)* role. That business role may grant admin rights to multiple database instances across the company. * **Technical Roles** represent entitlements in a specific application. An example is a DBA role in a specific instance. * **Business Roles** can include one or more Technical Roles, Groups, Resources, and other entitlement objects. * OpenIAM allows the creation of new role types with a custom set of attributes. This enables better alignment with the applications represented in OpenIAM. * **Groups** are used to grant access to a set of objects. Like Roles, they represent access to one or more objects. Groups can also contain other groups and be divided into specialized subgroups. A common example is Active Directory, which includes distribution groups and security groups. OpenIAM allows the definition of new Group types with custom attributes. * **Resources** can represent virtually anything that requires access control. A resource could be an application, a field on a screen, a URL, etc. **Resource types** allow the definition of new resource categories with custom attributes. * **Organizations** represent organizational structures such as companies, divisions, departments, and cost centers. OpenIAM allows new types of organizations to be created with custom attributes. The following sections provide a high-level overview of the access control model. ## Types As you integrate your applications with OpenIAM, you may need to extend the model to align with them. Each object above can be extended by creating a new **Type** — also known as a **Metadata Type**. Using Types, you can create new objects, and each object *can* have its own custom attributes. This lets you represent objects in OpenIAM with terminology that matches the target application. For example, integrating with Active Directory, AWS, and Salesforce requires different group types. To distinguish them, define a **Group Type** for each application: * AD Group. * AWS Group. * Salesforce.com Group. Each group definition may include attributes specific to its application. For instance, an **AD Group Type** may have attributes such as: * DN. * Group type. * Group scope. For out-of-the-box connectors, OpenIAM provides predefined types to simplify deployment and configuration. ## Permissions Permissions define fine-grained access to objects. For example, one user may have **READ + WRITE** permissions for a resource, while another may have **READ + WRITE + EXECUTE** permissions. Permissions are not limited to create, read, update, and delete (CRUD) operations. They can vary by application and business domain. For example, in **financial services**, a role in a loan approval system may have permissions tied to approval limits. In OpenIAM, permissions are referred to as **Access Rights**. Access Rights are used with other entitlement objects such as Groups and Roles. A set of Access Rights can be defined for each application type. ![Permissions](/files/69775a13cc933a06350638295058b321f3754c0a) ## Inheritance Each object listed above supports inheritance. This allows users to create base groups and roles that include a common set of entitlements required by one or more child groups or roles. ![Inheritance](/files/dd0d7d7fa3ed7a19f8de7462830d759bdffe6971) In the diagram above, a base role called **Developer** is entitled to an Active Directory group. The two roles that inherit from this base role also inherit that entitlement. This removes the need to replicate entitlements across each role. Proper use of inheritance simplifies the creation and maintenance of role definitions. ## Relationships Relationships in the OpenIAM access control model describe: * Access that is inherited. * Access that a Group or Role grants to a user. Access granted by a role to a set of entitlements is referred to as a **Direct Relationship** or **Explicit Assignment**. Access granted through inheritance is referred to as an **Indirect Relationship** or **Implicit Assignment**. ### This section covers * How the authorization manager works. * How users can define new access control objects. * How users can extend the model to map to their applications. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs-beta.openiam.com/access-control.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.