Defining and managing access is a key step in being able to govern identities across the enterprise. By defining the access control rules, OpenIAM can help answer a variety of questions such as:
- Which applications and entitlements should a user be entitled to during provisioning?
- Can a user SSO to an application?
- Should a field on a screen be visible, editable or read-only?
This section describes:
- How the authorization manager works
- How you can define new access control objects
- How you can extend this model to map to your applications.
Access Control Model Overview
Access control in OpenIAM is based on a Role Based Access Control (RBAC) model. The OpenIAM RBAC model consists of four (4) types of objects, listed below, which can be used to align the access control model with business needs and applications which need to be integrated with OpenIAM.
The following sections provide a high-level overview of the access control model.
As you start to integrate your applications with OpenIAM, you will find cases where you need to extend the model to better align with the end applications. Each of the above objects can be extended by creating a new
Metadata Type). Using types, new objects can be created which can also have their own set of custom attributes. This allows us to represent objects in OpenIAM using both terminology which familiar and aligned with the target application.
Consider that we may want to integrate with: Active Directory, AWS, and Salesforce.com. Each of these has a notion of groups. However, the manner in which groups are represented in each system are different. To distinguish between the groups of each application, we first define a group type of each application. ie.
- 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 attributes such as:
- Group type
- Group scope
For the out of the box connectors, OpenIAM provides pre-defined types to simplify the deployment and configuration process.
Permissions are used to define a fine grained access on an object. For example, a user may have READ + WRITE permissions to a resource where as another user may have READ + WRITE + EXECUTE permissions. Permissions do not need to be limited to CRUD operations. They may vary by application and business domain. For example, in Financial service, its 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.
Each of the objects listed above supports inheritance. In this way, you can create base groups and roles which contain a common set of entitlements which will be needed 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 which inherit from this role, will also be entitled to the Active Directory group of the parent. In this way, we don't need to replicate this definition across each role object. Using inheritance correctly will simplify the effort to create and maintain your role definitions.
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 an
Direct relationship or an
Explicit assignment. Access that is granted through inheritance is referred to as an
In-direct relationship or