RBAC vs. ABAC vs. ACL: Access Control Models for IAM

Since the advent of multi-user networks and operating systems (data center virtualization or cloud computing), several access control mechanisms have been developed to prevent unauthorized access.

In this article, we’ll take a look at the three most common access control mechanisms — ACL, RBAC and  ABAC — that organizations can use to support the overall Identity and Access Management (IAM) practice.

TLDR for access control models

Here’s the quick version: Access control is a mandatory activity for pretty much every single organization, particularly in the domain of Identity and Access Management. We can sum up these three control mechanisms like so:

• Often simplistic, Access Control Lists (ACLs) do have some limited use cases, particularly in legacy environments with few users.
• Role Based Access Control (RBAC) is both a strong foundation and a scalable long-term solution for many complex IT environments of small- to medium-sized organizations.
• For the most granular control, Attribute Based Access Control (ABAC) is likely your best solution.

Now let’s look at each of these in detail.

The role of Access Control Lists (ACLs) today

The most prominent control models started off as a simple list of mappings for every networked object: every device had a list of mappings. These mappings describe:

• Which entities can access the device
• What actions they are allowed to take

This simple model is called Access Control Lists (ACLs). Today, ACLs are obsolete in large networked systems and data center applications, where millions of users access hundreds of server systems and the IT workloads are distributed dynamically across multiple data centers. However, the relative simplicity of the ACL model still finds its relevance in legacy systems designed for computing tasks where the systems are accessed by a limited number of entities.

ACLs can be manually configured to control access at the Network Layer of the OSI model (possibly extendable to the Transport Layer by embedding network logic into the ACL systems). Low level data objects and devices that interface with a limited number of users, which do not require fine-grained IAM controls can effectively adopt the ACL access control mechanism.

Though ACL can be applied in certain scenarios, it remains ineffective where scalability, fine-grained control options and abstraction of the user identity is required, which is relevant for third-party IT services integrated into the system or governance controls focused on strong end-user privacy. 

How Roles Based Access Control works (Scalable IAM)

The Roles Based Access Control (RBAC) access control model takes a different approach to identity and access. Instead of defining the entities, RBAC identifies the roles, responsibilities and relationships that comply with various levels of the IAM access hierarchy. RBAC can be formally defined with three basic rules:

• Role assignment
• Role authorization
• Transaction authorization

(Learn how to manage data with RBAC principles and Splunk.)

Role assignment

A transaction is executed only if the subject is assigned the required role or individually approved for the requested transaction. This means that all users must be assigned an active role and involve exchange of information between the user and the network.

Role authorization

The role assigned to the subject must be authorized and remain active when the transaction process is requested. This ensures that an unauthorized role cannot be adopted by a subject, unless specifically assigned to them. This verification ensures that similar access permissions and policies do not automatically translate into role assignment and adoption by a subject — instead, that an additional verification of role authorization is required.

Transaction authorization

With transaction authorization, the transaction process must be authorized for the assigned role. The first two rules ensure that if a transaction process is authorized to a role assignment, the transaction will be executed. However, it does not enforce any additional access constraints to the transaction process itself.

For IAM policies focused on individual transactions that may not conform to a role-based policy mechanism, IAM organizations may choose to configure additional restrictions to the transaction process. This results in a highly scalable IAM governance and control mechanism, where predefined roles and responsibilities can be assigned to a growing user base. (Hence why RBAC is perfectly sufficient for many small- and medium-sized organizations with clear organizational roles.)

But what happens when the roles contain overlapping attributes that are difficult to distinguish and model with unique and isolated role assignments?

When to use Attribute Based Access Control (Granular IAM)

The idea behind IAM controls is to protect resources from unauthorized access and modifications. These resources can be objects such as data workloads, applications, IT services, devices or other software and hardware systems connected to the IT network.

To protect these objects from unauthorized access, organizations can devise policies that evaluate the request and render an access decision. As part of the RBAC controls, the role assignment can be seen as one of the attributes pertaining to the request.

For most large-scale IT networks, however, RBAC may be an insufficient subject qualifier considering that an evolving IT network grows in…

• Architectural complexity
• Volume of users
• Role assignments and responsibilities

This leads to permissions leakage between roles and makes it challenging to classify access requests based on the single attribute dimension — namely the role assignment itself.

So, IAM organizations might combine more attributes to establish a multi-dimensional decision framework to render access decisions. This is known as Attribute-Based Access Control (ABAC). These attributes can be related to the IAM policy and use elements related to:

• The subject
• Environment
• Action
• The objects

By consistently defining these attributes and the approved transaction processes for every object, ABAC gives the flexibility to identify permissions based on exhaustive decision criteria. The attributes processed by the transaction request are used to determine the association of the request with the permissions and privileges authorized by the IAM policy. This mechanism serves as a classical use case for AI tools that can be used to represent a decision system that evaluates multi-dimensional attributes data and renders an access control decision. These systems can learn from the available attributes data and improve continuously to realize an automated and autonomous IAM controls agent.

The ABAC mechanism scales particularly well in fast-growing IT environments, requires fewer policies and offers granular classifications between request attribute profiles.