From static roles to dynamic rules

The Role Based Access Control (RBAC) promise was to simplify administration of permissions for large numbers of users. RBAC models categorize users based on similar needs and group them into roles. Permissions are assigned to roles rather than to individual users. The objective is to reduce the number of assignments. The more users and permissions one single role captures, the greater the administrative efficiency gains.

Delivering on that promise is however difficult or impossible. In reality, the authority varies considerably not only between individuals but also for a single user over time. The role concept uses approximations for the sake of simplicity. At any point in time, permissions assigned to individual users by means of roles will therefore deviate from an ideal state.

Approximation comes at a cost. A never-ending struggle to refine role definitions and to achieve a sound segregation of duties must be maintained. This struggle has over time become accepted as a necessary evil rather than recognized as the effects of poorly designed access controls. The illustration reveals the problem. Users in the middle assigned both role 1 and 2 represent an unacceptable fraud risk. They can potentially subvert business critical processes. They probably do not need the permissions that combined create toxic combinations. But removing any of them will inflict on the ability of users in the other two groups to do their jobs. Thus, either you live with the risk or you start a new role engineering project. And you accept having to do so over and over again since the very purpose is to achieve approximations which by definition will not be exact and as a result will fail anew.

Attribute Based Access Control (ABAC)

Ideally, users should be assigned permissions which at any point in time represent a true reflection of current business rules, risk mitigating precautions and context-related security measures.

This is what the next generation entitlement management, Attribute Based Access Control (ABAC), delivers. ABAC implements business rules in context-aware and risk-mitigating policies. Rules combined in policies and policy sets become an exact definition rather than an approximation of authorizations based on business rules. They use attributes to describe when access should be permitted or denied. Attributes identify the user, the information asset, the action and the context in which access is being made.

The move from roles to rules thus allows the implementation of precise and fine-grained authorization. This in turn also lays the foundation for dynamic and context-aware authorization. Rules are interpreted in real-time while considering context-related attributes such as risk indicators, time and location, user behavior patterns, the relation between the user and the information asset, etc.

Where RBAC provides coarse-grained, predefined and static access control configurations, ABAC offers fine-grained rules which are evaluated dynamically in real-time.

Global scaling beyond old domains and firewalls

In older access control models the user population as well as the sensitive information assets were assumed to be known in advanced. In modern globally connected environments this is not necessarily true. A trusted identity provider may vouch for a previously unknown user's identity and provide descriptive attributes. But the user is not known in advance and cannot in advance be mapped to roles in the target system. With old access control techniques it is therefore difficult or impossible to manage access in information exchange across domain borders.

ABAC, by contrast, can use a broad set of descriptive attributes which are evaluated at run-time. ABAC does not depend on user IDs being known in advance. It easily supports scenarios of scaling both horizontally and vertically for secure information sharing across the Internet.

Leveraging RBAC investments made

ABAC rules mandate that permissions be granted or denied depending on the values of named attributes. For users, adequate "subject attributes" will often be roles. Roles therefore retain their value and serve as important privilege-giving attributes which help define the user when ABAC authorizations are made.

It is especially true considering their privilege-giving quality. The assignment of privileges to a user requires a managed and trusted process. The trustworthiness of the entire authorization system suffers if you easily can make such assignments without proper management approval. This is where existing roles fit in well in an ABAC system. They typically are already maintained in a reliable approval workflow and verified through regular re-certification procedures. As such, they are ideal as privilege-giving attributes.

In this sense Attribute Based Access Control (ABAC) leverages investments made in RBAC models while moving beyond. The problem with the toxic combination in the example above could for instance be resolved without a change in the role concept. An ABAC rule can state that "yes, if you have both role 1 and 2 you may use permission 1.C provided you have not already used the permission 2.C on that same information object since the combination would constitute an SoD violation". Thus, roles are maintained and used but their limitations have been overcome.