What is Attribute Based Access Control?

Attribute Based Access Control (ABAC) is defined as “An access control method where subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions.”

ABAC relies on user attributes for authorization decisions. ABAC policies are rules that evaluate access based on the following four sets of attributes:

Subject – the attributes concerning the person or actor being evaluated
Resource – the attributes of the target or object being affected
Action – describe the action to be performed on the Resource
Environment – includes attributes such as the time of the day, IP subnet, and others that do not relate to either the Subject or the Resource.

Figure 1: NIST SP 800-162 ABAC Definition

ABAC Benefits

The primary advantage of ABAC lies in preventing application developers from hardcoding a static list of roles and oversimplifying their authorization source code. Instead, ABAC requires them to centralize all authorization decisions and make runtime calls based on the Subject, Resource, Action, and Environment request attributes. Another significant benefit is ABAC's simplicity, which can facilitate understanding how a rule grants access to a resource. In contrast, RBAC can seem foreign to many users, and during its early adoption phase, the levels of abstraction can pose challenges for an IT team.

ABAC's flexibility is another added advantage. As long as the necessary data is available, almost anything can be represented as a rule-based query with ABAC. For instance, a rule evaluated at runtime in a login session can use contextual information – even information passed in via SAML claims or JWT tokens. In contrast, a standard RBAC engine would not evaluate this type of information when delivering the role membership for a user to the application.

ABAC Primary Benefits

ABAC enforces centralized management of authorization policies.
ABAC makes it easy to specify access rules as simple queries.
ABAC rules can be extraordinarily fine-grained and contextual.
ABAC rules can evaluate attributes of Subjects and Resources not inventoried by the authorization system.
ABAC rules require less maintenance and overhead since they do not necessitate the creation or maintenance of the structure on which an RBAC model depends, such as roles and resource locations.

Figure 2 below shows an example of an actual ABAC policy implemented in an EmpowerID demonstration. Here, our application asks if Alice can View Bob's X-Ray. Our ABAC decision engine bases its decision on a complex ABAC policy (labeled Policies in the figure). The first policy check, Rule1, verifies that the action being taken is "View." The next extended requirement for Rule1 is that the company is not in "Emergency Mode," meaning it is not in the midst of a crisis. However, to increase rule flexibility during a crisis, some roles may be granted additional permissions to enable those who would not typically be allowed to perform those activities to assist. The next check only allows "View" if the person is currently on the "Local Network." (Some sensitive activities might not be allowed if the person is outside the corporate network.) The next check confirms that the user performed a Multi-Factor Authentication ("MFA") with a Level of Assurance ("LOA") of at least "2". This type of authentication refers to a stronger authentication method, like a physical token or mobile push. The policy also checks to see if the user is a member of the Doctors role and that their status is not currently set to out of office. Finally, the checks ensure that the X-Ray has neither been flagged as "Confidential" nor the Subject has a relationship of the type Attending Physician.

Figure 2: Elaborate ABAC policy showing the potential of ABAC

ABAC Weaknesses

The first challenge with implementing policies like the previously discussed example is obtaining and evaluating information at runtime. In the policy example, acquiring information such as user nationality, company status, out-of-office status, and network login sessions or MFA status would require queries to various systems (Figure 3). This raises two crucial questions for your organization regarding your ABAC system:

How long would it take to retrieve this information?
Would this delay be acceptable to your organization and its users?

Figure 3: Sources of attribute data for a complex runtime ABAC policy evaluation

For end-user applications, where even an additional half-second delay can be considered unacceptable, such lag poses a significant challenge. Moreover, this assumes that all these systems provide an API that can be called to retrieve this data, which many do not. It becomes clear that implementing a powerful but complex demo policy would be extremely difficult in a real-world environment.

Another challenge with ABAC is that the Just-In-Time (JIT) evaluations of its rules often lead to a disconnect or lack of an auditable link between the rule-based policies and the resources they protect. ABAC policies are inherently non-relational, unlike the relational nature of RBAC, where users are related to roles, which, in turn, relate to permissions for resources. This lack of a relational concept is at the core of many of ABAC's weaknesses.

In terms of auditing, ABAC makes it difficult to answer standard questions such as:

How do I see which users have access to my application and how each was granted access?
How will application owners be trained to read and interpret the rules and research all the source information?
Given that attribute values' origin could come from another system or be contextual to a single login session, how would the application owner determine who matches the rule?
How would the application owner grant direct access to a user in an ABAC model?
As a delegated admin, who can add or remove users from specific groups that might be used in many ABAC rules?
How would a user know that adding someone to a group grants them access to Application A?
As an auditor, how would I audit how access is granted to the application and who is giving the access?

Figure 4: A Common Standard Auditor's Question

ABAC’s Primary Weaknesses

ABAC makes it extremely difficult to perform a "before the fact audit" and determine the permissions available to a specific user.
ABAC systems can experience an explosion of possible rule combinations, similar to the "Role Explosion" in RBAC.
ABAC systems with complex rules from multiple attribute sources can be unacceptably slow to answer authorization queries, unless rules are kept simple and do not access data from various source systems.

ABAC Challenges

Figure 5: The Who, What, and How of ABAC Challenges

Indeed, one of the significant challenges with ABAC is finding individuals within an organization who possess the required skills and knowledge to write effective authorization policies. Crafting rich, accurate, and efficient policies demands a combination of solid business knowledge and a deep understanding of security.

XACML, developed 18 years ago as a standards-based language built on XML, was designed for authoring authorization policies. The original idea behind XACML was that business users would be the ones creating these policies, as they would have the best understanding of who should have access to specific resources and activities from a business perspective. However, writing XACML policies is a highly complex task, and most business users lack the technical expertise or simply do not have the time to write IT policies.

This challenge highlights the need for a more user-friendly approach to writing authorization policies that can be accessible to business users without requiring in-depth technical expertise. One potential solution is to develop more intuitive policy authoring tools or languages that simplify the process of crafting and managing authorization policies. Alternatively, organizations could invest in training programs for business users to better understand the technical aspects of writing policies or provide support from IT teams to help bridge the gap between business requirements and technical implementation.

EmpowerID Admin Guide 23