Designing business roles

Roles in OpenIAM can be categorized into the following:

  • Technical roles - Roles found in business applications that are being used to control access within that application; ie Roles in, AWS, Oracle RDBMS
  • OpenIAM Access roles are roles which determine what you are allowed to do within the OpenIAM UI
  • Business roles are roles defined in OpenIAM which grant a bundle of access based on either birthright access or other attributes aligned with an organization's structure. For example, a user can become a member of the Developer role if they are in the Department is Engineering and their job title is either Developer or Senior Developer.

For organizations that want to implement role based provisioning, it is essential that adequate time be devoted to designing business roles. Since OpenIAM allows direct entitlement, it is not essential that all roles are defined up front. Primary / essentials roles can be defined in the initial stages, setting up a framework which can then be expanded upon over time.

This section describes factors that should be considered while designing your roles. This section is not intended to be an authoritative document on role design / modeling.

Role discovery

An initial step in the role design process is to "discover" existing roles, i.e. the access that users already have. This information can be found both in OpenIAM and in your last access certifications. If OpenIAM has been deployed for IGA and already connected to your applications, then you will already have a full user profile in OpenIAM. If you have not, but have a previous user access certification available, then you can also use that.

It's inconceivable that in mid to large organizations that you will be able to review the access of the entire organization at once. We recommend looking at a small group of people in a similar work area such as a department and scaling the analysis from there. You can further limit the scope of the analysis by looking at people who have a similar job title or job code. As you compare them side by side, you will notice that these will have largely similar access but there will be variations in each user's access. One reason for this discrepancy is that in the absence of an IAM system or strict access controls, users tend to accumulate access over a period of time, access which they may not need.

To provide a more tangible example, assume that we are analyzing a technical department which has a distributed team that has access to several applications. That matrix may look like the one below.

User Profile and AccessUser 1 User 2 User 3 User 4 User 5
Job Title Senior DeveloperSenior DeveloperSenior DeveloperDatabase AdministratorDatabase Administrator
Location New York New York Munich Munich New York
Application: Active Directory
OU ou=us,ou=engineering,dc=mycorp,dc=comou=us,ou=engineering,dc=mycorp,dc=comou=eu,ou=engineering,dc=mycorp,dc=com ou=eu,ou=engineering,dc=mycorp,dc=com ou=us,ou=engineering,dc=mycorp,dc=com
Group Memberships
  • Engineering
  • US Engineering
  • Developer
  • Java Developer
  • Engineering
  • US Engineering
  • Developer
  • .NET Developer
  • Engineering
  • EU Engineering
  • Developer
  • Engineering
  • EU Engineering
  • DBA
  • PostgreSQL DBA
  • Engineering
  • US Engineering
  • DBA
  • Oracle DBA
Application: Oracle Database (host name.schema)
  • DBA
Note: The above example is limited in nature and only an example to help start this process. It is by no means a universally generic matrix. In practice, your users will have many more applications and entitlements. Also, the attributes that you consider will vary based on the business domain. For example, in banking, credit or loan function, may have attributes such as Loan limit approvals.

Role design

From the example above, we can see commonality between users in the same type of job, but we also see some variations which in this case are the result of location and specialization. There are some obvious roles that we can extract from this simple example. The most obvious roles are shown in the diagram below.

Role design

While the above roles may be a starting point, they don't go far enough. We can iterate through this process to create a model that is closer to real world alignment. The diagram below shows the result of the second pass through this design.

Role design based on inheritance

The diagram below approaches role design using inheritance.

Role design with inheritance

While we have greater coverage than in our first iteration, a number of parameters are still not included in this design. Further, we are starting to see the number of roles starting to grow quickly.

While developing our role hierarchy, it's important keep the following in mind:

  • Performance implications resulting from a role hierarchy that has a large number of entitlements and many layers of inheritance.
  • Maintainability - impact of updating parent roles on their children.
  • Avoid a role explosion problem.

Overall, a design based purely on inheritance may be too rigid to handle real world changes.

Hybrid role design

Since OpenIAM supports users having more than one role, a hybrid role design which leverages location and job function may prove to be more flexible than an inheritance only design. Since some of the access in our example is based on location, we can introduce an organization object into our design as shown below.

Role design with inheritance and organizations

The role model above introduces two department (organization) objects which are used to define entitlements which are associated with location. These two objects remove four (4) roles that were defined in our second iteration of the model. Moving the location part of the design to another model allows introducing job specific roles such as Java Developer or Oracle DBA without having to account for the location. In doing so, we avoid a potential role explosion problem.

Note: There isn't a single approach which will work for all organizations. The design of the access control model should be driven by your business needs. An experienced IAM engineer or architect can assist your organization if needed.

Documenting the role design

Once a high level design has been created, we need to document the design so that it can be handed off to the implementation team. The table below describes a simple approach to documenting roles

Role nameName of the role
Role descriptionSummary of what this role is supposed to do
Parent roleName of the parent role, if this role inherits behavior from another role
Role entitlementsList of application applications + entitlements and permissions which are granted by becoming a member of this role
Membership criteriaDefine the criteria to become a member of this role. For example: Title = "Developer" and Department = "MyDept"
Exclusion criteriaConditions under which a person cannot become a member of a role. For example, user is already a member of role called "System Admin"