Definitions

Definition 1

Role Explosition is a phenomenon that is sometimes observed in relation to the implementation of Role-Based Access Control. It is characterized by the uncontrolled increase of roles, sometimes with very few members per role. This phenomenon reduces the benefits yielded from Role-Based Access Control and may constitute a liability in extreme cases.

Possible causes for Role Explosion comprise:

• Insufficient role engineering competencies,

• Lack of a disciplined and consistent role engineering process (including: lack of standardization, not deleting obsolete roles, creating duplicate or highly similar roles, etc.),

• Requiring that all access permissions be inherited from roles,

• Flawed attempt to use Role-Based Access Control to manage complex, dynamic or fine-grained identity attributes with their Cartesian product.

The consequences of Role Explosion may comprise:

• Increased cost and complexity in managing roles,

• Increased difficulty to use and understand roles,

• Increased difficulty to analyze and audit roles and access permissions.

Possible solutions to avoid role explosion include:

• Defining and implementing a robust role engineering process,

• Setting up a regular role review and optimization process,

• Training role engineers,

• Limiting expectations from Role-Based Access Control (it isn’t a silver bullet),

• Supporting temporary roles,

• Complementing Role-Based Access Control with Attribute-Based Access Control, Policy-Based Access Control or other access control methods,

• Optimizing birth rights,

• Delegating fine-grained access management to the underlying system.

Conceptual Model

Open

Examples

Bob started to implement Role-Based Access Control in his organization. He did not plan his project, neither designed a target role model and failed to define a naming convention. Instead, whenever Eve, the business manager, came to him asking for new roles, he hastily created them to satisfy her without analyzing how the business requirements fitted the role model. 6 months later, Alice was appointed as the new IAM Manager. Looking at these roles, she couldn’t believe how messy the RBAC was. She decided to restart everything from a blank sheet of paper.

Related Terms

Quotes

Make Roles Reusable – If only one person in the whole organization is assigned a particular role, maybe that access shouldn’t be managed via a role at all. Make sure the roles you define are applicable to groups of people. Avoiding “role explosion” requires setting carefully engineering limits to the coverage and assignment of roles. Having a small, well-controlled, and extensively used role model is far better than a behemoth that no one understands or uses.

RBAC suffers from an issue called the role explosion problem, which we illustrate with the following example.

Example 28 Assume we want to develop an RBAC policy for a university. In this organization, each user denotes a student and each permission denotes a course. We assume that there are 10,000 students and 100 courses. The RBAC policy should authorize each student to view the contents of only those courses in which the student is enrolled.

Two different students rarely enroll in exactly the same set of courses. In the worst case, the RBAC policy would require one role for each student. Hence, an RBAC policy can become as impractical as an access control matrix in this scenario as the number of roles is substantially large.

To solve this problem, ABAC (Attribute-Based Access Control) policies were proposed. An ABAC policy is a set of rules, where each rule describes a set of conditions based on the attribute values of users and permissions [77, 69]. An example of an ABAC policy can be seen in stores that sell alcoholic beverages only to people who are at least 21 years old. The user (i.e., the client) is granted permission to buy alcohol only if his age attribute has a value greater than or equal to 21. Observe here that the policy grants permissions according the user’s attribute values.

Role Based Access Control (RBAC) is a strategy used by many organizations to authorize access to resources. However, RBAC has a dark side: if roles are used to reference each unique access requirement, the number of roles can grow exponentially. In fact, some organizations have more roles than people! This is known as “role explosion”.

Additionally, the subject qualifiers, such as identity and roles, are often insufficient in the expression of real-world AC needs. RBAC makes a decision based on the subject’s association with a role. RBAC does not easily support multi-factor decisions (for example, decisions dependent on physical location, and specialized training such as for Health Insurance Portability and Accountability Act (HIPAA) records access; recent training on HIPAA data protection may be a prerequisite to view medical records.) RBAC role assignments tend to be based upon more static organizational positions, presenting challenges in certain RBAC architectures where dynamic access control decisions are required. Trying to implement these kinds of access control decisions would require the creation of numerous roles that are ad hoc and limited in membership, leading to what is often termed “role explosion”.

There are three drawbacks with RBAC: 1) it needs a substantial effort to define roles and assign them to users 2) an administrator needs to introduce a new role to cover discrepancies, leading to role explosion problem[17] 3) RBAC is not suitable for a cross-domain access management because reaching to agreement that what permissions are associated with a role is difficult [18]. Due to these barriers and to provide a finer level of access control, many service-oriented platforms have shifted to Attribute Based Access control.

Lessons Learned

The following are a summary list of lessons learned based on a number of large RBAC implementations. This list is not meant to be comprehensive, but should serve as lighted guideposts to avoid costly pitfalls across all phases of the RBAC implementation cycle.

• Role definition is time and resource intensive: Organizations try to create roles for all permutations of access, resulting in too many roles to manage (e.g., one role per user leading to role explosion).

Several phenomena observed in practice can limit RBAC’s strengths.

Role explosion

• P1: Users’ individuality, locality, and particularity give rise to roles with only a few members, contributing to role explosion.

• P2: There might be many dynamic context-specific attributes that affect users’ permissions, contributing to role explosion.

Phenomena in the RBAC context of use which limits its strengths

• P1: In RBAC all assignments of users to permissions need to be granted via roles; this may give rise to roles with a few members, contributing to the phenomenon called ‘role explosion’.

• P2: There may be many context-specific attributes which affect users’ permissions; coping with this contributes to the phenomenon of ‘role explosion’.

P1 and P2 are causes of role explosion, and if they happen, then assumptions A1 (users do not acquire permissions due to individual attributes – they share profiles which determine roles) and A2 (the number of roles is much smaller than the number of users to be granted access) are not satisfied. Conclusions 8 and 9 show that total consensus about the truth of A1 and A2 is lacking; our explanation is that P1 and P2 do happen sometimes (but not always).

Bibliography

See Also