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 Salesforce.com, AWS, Oracle RDBMS
• OpenIAM Access roles - 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 for 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; ie. 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, than 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 department and scaling the analysis from there. You can further limit the scope of the analysis by looking at people 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 an technical department which has a distributed team that has access several applications. That matrix may look like the one below.

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 some obvious roles that we can extract from this simple example. The most obvious roles are show in the diagram below.

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 second pass through this design.

Role design based on inheritance

The diagram below, approach role design using inheritance.

While we have a 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 role starting to grow quickly.

While developing our role hierarchy, its 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 maybe too rigid to handle real world changes.

Hybrid role design

Since OpenIAM supports users have more than one role, a hybrid role design which leverages location and job function may prove to be more flexible than a 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.

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 to introduce 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.

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