Benefits of ABAC Over Other Approaches: Blog; Role-based Access Control (RBAC) vs Attribute-based Access Control (ABAC) comparison diagram; RBAC provides access to resources or information based on user roles, whereas ABAC provides access rights based on user, environment, or resource attributes. In the RBAC model: Admin assigns users to appropriate roles. Users are assigned to roles. Roles define authority level. Permissions are authorized for specific roles. In the ABAC model: Admin specifies access authorization rules. Examples of Resource attributes include Creation date, Resource owner, Data Sensitivity, etc. Examples of Subject (user or service) attributes include Name, Role, Security classification, etc. Examples of Environmental attributes include Access time, Data location, Threat levels, etc. User role is just one of the attributes that can be used for policy decisions. Example scenario for RBAC: Permission to Access = HR (Role) for All data in an HR Table (Resource); Example scenario for ABAC: Allow Access = HR (Role) + US (Geolocation or Country of Origin) for US Payroll related columns in an HR Table (Resource)

Understanding the Benefits of ABAC Over Other Approaches

You’ve likely intuited several ways ABAC is superior to other approaches, but I’ll run through those benefits more explicitly in this section: better security, authoritative claims, detailed compliance, change resiliency, real-time enforcement, and the value of explicit frameworks. I’ll also cover a few direct comparisons to identity- and role-based models.

Considering more context in each access decision provides better security because you no longer have a single point of compromise. Not only is it a foundational concept for a Zero Trust security strategy, but it prevents some dangerous attack vectors. ABAC models establish stricter boundaries between systems and even to information within those systems. Risk-based decision-making can deny access based on detected threat scores of the user, device, network, and more. 

For example, to reduce risks in an identity-based model–often caused by over-permissioned or poorly managed roles–some organizations implement two-factor authentication, but there are many methods for bypassing it. Two-factor is no substitute for an additional layer of authorization that evaluates environmental attributes to block attempts from a risky source, failing closed even if the two-factor authentication check passes.

ABAC models can source attributes from any system or repository, reducing the risk of incorrect or out-of-date information that must travel multiple silos and layers of abstraction before it can be used in access decisions. Continuous evaluation of service or project status, training records, activity results, or security clearances leverages authoritative sources to grant claims. In fact, you may see attribute-based access controls referred to as claims-based access controls to emphasize the value created by cutting out the manual steps to establish claims.

The different factors collected for attribute-based decision-making provide detailed visibility for monitoring internal and external threats, and this same telemetry improves the ability to demonstrate compliance. ABAC models capture a more complete understanding of access, with better ways to dictate the conditions of access and appropriate use of information. What have I requested access to view? Why? How should I be permitted to use it? The levels of abstraction required to make ACLs and RBAC models function expose sensitive information like security clearances across multiple systems and make it challenging to address compliance mandates, let alone trace back why access was approved or denied. 

This same level of abstraction required by RBAC models impacts change resiliency: It’s hard to identify all locations where updates are required, which increases administrative time spent to maintain data security. It also increases the cludge factor. An RBAC model describes–within its initial structure of roles and groups–how access will be granted. So if an organization experiences a reorg, a merger or acquisition, a new regulatory mandate, or a drastic change to the way their workforce must operate, it can’t adjust without forcing or retrofitting. The time needed to respond to market and workforce fluidity prevents the organizations from responding to change in a timely manner.

By contrast, ABAC models depend on descriptions of users, services, data, and environmental facts. Factual descriptions require no crystal ball to forecast how access controls might need to be changed in an uncertain world; administrators can rewrite policy against existing attributes–or assign new ones–to accommodate a changed world. Additionally, ABAC avoids the need for capabilities to be assigned directly to roles or groups. This is subtle, but it means an administrator can manage policy without needing to directly modify (and likely proliferate) roles to address change. Change is why organizations wind up with more roles than employees. 

Speaking of change, RBAC models are not suited to enforcing real-time changes, especially those required in cloud-based environments. As the two-factor example above made clear: context is everything. More dynamic attribute-based policy ensures data and resources are made available just in time to those who need them.

Role-based Access Control (RBAC) vs Attribute-based Access Control (ABAC) comparison diagram; RBAC provides access to resources or information based on user roles, whereas ABAC provides access rights based on user, environment, or resource attributes. In the RBAC model: Admin assigns users to appropriate roles. Users are assigned to roles. Roles define authority level. Permissions are authorized for specific roles. In the ABAC model: Admin specifies access authorization rules. Examples of Resource attributes include Creation date, Resource owner, Data Sensitivity, etc. Examples of Subject (user or service) attributes include Name, Role, Security classification, etc. Examples of Environmental attributes include Access time, Data location, Threat levels, etc. User role is just one of the attributes that can be used for policy decisions. Example scenario for RBAC: Permission to Access = HR (Role) for All data in an HR Table (Resource); Example scenario for ABAC: Allow Access = HR (Role) + US (Geolocation or Country of Origin) for US Payroll related columns in an HR Table (Resource)
RBAC vs ABAC Model

Attribute-based policy also supports more flexible and comprehensive frameworks like the Extensible Access Control Markup Language (XACML). Why is this important? Most compliance mandates start in legal or natural language and there’s a translation process from a written document into code that can be enforced programmatically. The more precise the technical language can be–with fewer levels of abstraction–the more accurately and consistently the policy can be enforced.

If policy is the new perimeter, then it needs to be enforced not just against applications and devices–which have been the domain of IAM systems–but against data and resources. Ironically, identity systems addressed the problem of credentials stored in multiple ACLs by centralizing them into an authoritative source that was more transparent, compliant, and easier to use. There’s a lot we can learn from the identity and access challenge to address the even larger problem that protecting data and resources presents. RBAC models–which include IAM solutions by extension–introduced user attributes that increased the scalability of managing authentication. But subject qualifiers like roles and groups alone can’t achieve the granularity that today’s dynamic and increasingly contextual business demands.

Part 4/7 ABAC Blog Series: Policy is the New Perimeter