Introduction to access control

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 (4) primary entitlement objects listed below. Using these objects, a custom model can be defined to meet business requirements and represent the applications used by the business in a familiar manner.

• 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 required to perform a job function. For example, an admin in the DBA team may be a member of the Database Administrator (DBA) role. Such a business role may grant admin rights to multiple database instances within 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, etc.
  • 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 has distribution groups, security groups, etc. 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 it with your specific applications. Each of the above objects can be extended by creating a new Type (also known as a Metadata Type). Using Types, new objects can be created, and each object can have its own custom attributes. This enables users to represent objects in OpenIAM using terminology consistent with the target application.

For example, integrating with Active Directory, AWS, and Salesforce.com requires distinguishing between different types of groups. To differentiate them, we 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 user 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 corresponding to loan approval amounts.

In OpenIAM, permissions are referred to as Access Rights. Access Rights are used with other entitlement objects such as Groups or Roles. A set of Access Rights can be defined for each type of application.

Inheritance

Each of the objects 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.

In the diagram above, a base role called Developer is entitled to an Active Directory Group. The two roles inheriting from this base role will also be entitled to the parent Active Directory group. This eliminates the need to manually 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.