Access Control Model Overview

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 admin
• Workflow based approval model
• Access for a limited time period

OpenIAM RBAC model consists of four (4) primary entitlement objects that listed below. Using these objects, a custom model can be defined to meet business requirements as well as represent the applications being used by the business in a manner that is familiar to them.

• Roles - can be categorized as Business Roles and Technical roles.
  • Business roles - Are usually associated with a person job. As such, they can grant access to a collection or applications or functions required to perform a job function. For example, a person who is 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 many database instances that a company may have.
  • Technical roles represent entitlements in a specific application. An example is a DBA role in a specific instance.
  • Business roles can consist of one or more Technical roles, Groups, Resources, etc.
  • OpenIAM allows for the creation new types of roles with a custom set of attributes. This allows better alignment with the applications that we need to represent in OpenIAM.
• Groups - are used to grant access to a set of objects. Like Roles, they are used to represent access to one or more objects. Groups may also package other groups. Groups can also be segregated into specialized groups. A common example can be found in Active Directory which has distribution groups, security groups, etc. OpenIAM allows you to define new types of Groups with a custom set of attributes.
• Resources - can be used represent virtually anything that you want to be able to grant access to. A resource could be an application, a field on a screen, a URL, etc. We can use Resource types to define new types of resources with a custom set of attributes.
• Organizations - Organizations are used to represent organization objects such as company, division, department, and cost-center. OpenIAM allows new types of organizations to be created with a custom set of attributes.

The following sections provide a high-level overview of the access control model.

Types

As you start to integrate your applications with OpenIAM, you will find cases where you need to extend the model to better align it with the end applications. Each of the above objects can be extended by creating a new Type (aka Metadata Type). Using types, new objects can be created where each object can have their own set of custom attributes. This allows users to represent objects in OpenIAM using terminology that is consistent with the end application.

Consider that you may want to integrate with: Active Directory, AWS, and Salesforce.com. Each of these includes a notion of groups. However, the manner in which groups are represented in each system are different. To distinguish between the groups in each application, we define a group type of each application first, being:

• AD Group
• AWS Group
• Salesforce.com Group

The group definition of each can include attributes specific for each application. For example, the AD Group Type may have such attributes as:

• DN
• Group type
• Group scope

For the-out-of-the-box connectors, OpenIAM provides pre-defined types to simplify the deployment and configuration process.

Permissions

Permissions are used to define a fine-grained access onto an object. For example, a user may have READ + WRITE permissions to a resource, whereas another user may have READ + WRITE + EXECUTE permissions. Permissions are not necessarily limited to CRUD operations. They may vary by application and business domain. For example, in Financial services it's possible to have a role in a Loan Approval system, where the permissions represent loan approval amounts.

Permissions in OpenIAM 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. In this way, a user can create base groups and roles, containing a common set of entitlements required across one or more child groups or roles.

In the diagram above a base role called "Developer" has been entitled to an Active Directory Group. The two roles inheriting from this role, will also be entitled to the parent Active Directory group. In this way, we don't need to replicate this definition across each role. Using inheritance correctly will simplify the effort to create and maintain role definitions.

Relationships

Relationships in the OpenIAM access control model describe:

• Access that is inherited
• Access that a Group or Role entitles a user to

Access that a role grants to a set of entitlements is referred to as a Direct relationship or an Explicit assignment. Access that is granted through inheritance is referred to as an Indirect relationship or Implicit Assignment.