How does ABAC (Attribute-Based Access Control) compare to RBAC (Role-Based Access Control)?

Role Based Access Control (RBAC) was originally introduced to simplify the administration of access permissions, by avoiding direct assignment of them to individual users, and  increasing the level of security by facilitating a mechanism to enforce Least Privilege and Separation of Duty principles.

Although RBAC is a well-defined model, most large RBAC projects turn out to be very costly and almost impossible to finalise. The main issues with these projects are:

• Interoperability - difficulties to agree on a set of roles with a common meaning that can be shared between applications, platforms, domains and enterprises.
• Role explosion - too many roles without clear organisational definitions need to be administered. In some cases the number of roles has become larger than the number of users in the enterprise.

The interoperability issue is due to the fact that "role" is used in many different ways and there is no real consensus regarding the terminology. A role can refer to a job function within an organisational structure, a group and or a name for a collection of access permissions. However, a job function may have more than one name in different applications and domains, which of course, leads to confusion and a large number of non-interoperability issues.

The role explosion issues is due to the fact that RBAC, similar to traditional access control models Access Control List (ACL) and Mandatory Access Control (MAC), defines access permissions statically in the form of a snap-shot without considering the context of the access. Capturing the context, including the dynamics of the environment in which access permissions can be defined, would mean defining a large set of roles including permissions for each possible context. Moreover, defining  fine grained access permissions would also create many sets of permissions causing role explosion.

RBAC only focuses on subjects and the permissions granted to them. A user can be assigned multiple roles and thereby indirectly acquire permissions to related resources. However, ABAC is quite the opposite, all aspects of an access request are considered and identified by attributes: the subject who is demanding access, the action which the subject wants to perform, the resource being accessed and the environment or context in which access is requested.

This all-inclusive approach makes ABAC an ideal choice when finer granularity and context-aware authorizations are required. ABAC can be used to create portable and reusable policies which need to be enforced consistently across multiple platforms and applications.

In ABAC permissions are defined in terms of privilege-giving attributes. Instead of defining new roles to represent sets of access permissions ABAC defines the permission sets by combining the privilege-giving attributes. For example, the three attributes being an employee, having a driving license and being a Swedish citizen may in different combinations give different sets of access permissions. Potentially there would be 8 (2³) different sets of access permissions, hence in RBAC 8 different roles that can be named and need to be managed. But in ABAC we only need to manage the 3 well understood privilege-giving attributes, which is of course a much simpler task than managing 8 different roles that in most cases do not have any meaning in the organisation.