Like the Authentication service, the Authorization manager plays a critical role in the OpenIAM platform. The authorization manager helps 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 will 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
The OpenIAM Authorization Manager is based on a Role Based Access Control (RBAC) model which consists of the following objects:
The model allows you to define entitlements at the appropriate level. For example, some permissions can be granted based on a person’s job function or role. Other access may be granted based on their organization membership. For example, we can assign to a department access to a set of Groups and network file shares.
The overall access that a person has, is determined by the union of all entitlements defined across these various objects.
The sections below describe concepts which are used across the access control model
Each of the objects listed above supports inheritance. In this way, you can abstract away permissions which are common and then create specialized objects as shown in the diagram below.
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. As you work with the OpenIAM UI, you will see cases where access which is gained through inheritance is refered to as an
implicit assignment. Where as a direct entitlement, like the on found on the base role, is viewed as an
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 using Metadata-types. Using Metadata-types, we can create new types which can also have their own set of custom attributes. Consider that we may want to integrate with Active Directory and import all Active Directory Groups into OpenIAM. While we can represent AD Groups as OpenIAM groups, it would beneficial if we can create a new Metadata Type called "AD Group Type". This group can have custom attributes to capture details about the group such as: DN, Group type, Group scope, etc.
This concept can be applied to all four objects.
For the out of the box connectors, OpenIAM pre-defined types to simplify the deployment and configuration process.
In addition to being able to draw relationships between entitlement objects, access rights can be used to define what a person can do on the target object. Consider that we can grant access to a “Resource” like a network drive. It’s not enough to just grant access to the network drive. We need to be able to setup permissions like Read, Write, Modify. These permissions in OpenIAM are defined through “Access right”.