Role Explosion

Cartesian product: Let’s have roles for bank teller, supervisor and branch director. Let’s operate in London, Berlin and Bratislava. We need a role for London teller, Berlin teller, …​ 9 roles total. The number of roles grows very quickly.

Atomization: Cartesian product can sometime be avoided by decomposing roles to re-usable re-combinable units. Combine them to a "higher-order" roles using role hierarchy. This gives us 6 roles instead of 9. Unless the teller shares part of the access rights with janitor. Then we need Basic branch office access role, Teller’s IT access role and a Teller role that combines these two. Now we have 8 roles. The number of roles still grows quite quickly.

Unique access or policy exceptions: Many employees have one-of-a-kind set of access rights. Any attempt to fit them into the roles will inevitably result in a number of roles that is equal or greater than the number of such employees. This is quite pointless.

Lack of policy: RBAC may be used as an "alternative" to policy. If we do not know what the access control policy is, we just set up some roles and we are fine. This usually leads to high number of roles, as the roles are often created without much oversight or coordination. Duplicates (roles with the same set of permissions) are quite common.

Poor role management: Roles, as all identity management concepts, have their lifecycle. Role is created, maintained, updated, and then finally it is decommissioned. As role management is quite a demanding tasks, organizations are often cutting the corners. Roles are created, as they are needed. There may be few updates to roles, usually adding more permissions. However, roles are almost never deleted, as there is very little motivation to do so. This leads to ever-increasing number of roles.

Attribute-Based Access Control (ABAC) and Policy-Based Access Control (PBAC): The principle is that instead of having roles there are expressions that computes access rights. The expressions take user attributes as parameters. It seems to be very flexible, perhaps a bit too flexible. It replaces formal structure of roles with logic. That means programming, instead of configuration. Even worse, for ABAC/PBAC to work properly the policy must be known, well-specified and formalized. This is much harder than it may seem. It is also quite difficult to apply ABAC policies directly to provisioning, as ABAC often relies on context data that are not available at the provisioning time. ABAC/PBAC may solve the problem of role management, but does it also solve the generic problem of policy complexity and management?

RBAC, but forget about least privilege: Create "bigger" roles than what would the principle of least privilege dictate. Over-provision the users by purpose: create roles that grant much more permissions than they should grant. This improves role re-use and keeps the number of roles manageable. Although it results in a less secure situation it may be good approach for some environments.

Spice up roles with some logic: That usually means adding rules to make roles more generic. E.g. instead of creating London teller create a parametric role Teller that takes locality from user profile as a parameter, and computes the path to the home directory. This is somewhere between ABAC/PBAC and static RBAC. It has good features from both approaches and seems to be the most popular choice for provisioning systems. E.g midPoint has a very feature-rich support for Policy-Driven Role-Based Access Control.

Manage the chaos: Let users request access rights, let others approve it. This is the access request process. The obvious problem is how to revoke the unneeded rights. There needs to be yet another process to review and revoke them, usually called certification. However, certification campaigns require huge effort. This is a compromise between security and usability as there is always someone who have approved and/or certified what he shouldn’t have. Especially considering the fact that the approvals are often done by "I just look at it and if it seems OK I approve". It is difficult to enforce good scrutiny during approvals especially if someone has to approve hundreds of requests each day.