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 upon 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 key advantage of ABAC is that it does not allow application developers to hardcode a static list of roles and oversimplify their authorization source code. Rather, ABAC forces them to centralize all authorization decisions and make runtime calls for a decision based on the Subject, Resource, Action, and Environment request attributes. Another key benefit is the simplicity of ABAC, which can make it easier to understand how a rule grants access to a resource. In contrast, RBAC does seem foreign to many users, and, especially during the early phase of its adoption, the levels of abstraction can be challenging for an IT team.

One other added advantage of ABAC is its flexibility. With ABAC, as long as the necessary data is available, almost anything can be represented as a rule-based query. For example, 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, when delivering the role membership for a user to the application, a standard RBAC engine would not evaluate this type of information.

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 that are not inventoried by the authorization system.
ABAC rules need less maintenance and overhead because they do not require the creation or maintenance of the structure on which an RBAC model depends, e.g., roles and resource locations.

Figure 2 below, shows an example of an actual ABAC policy implemented in an EmpowerID demonstration. Here, our application is asking if Alice can View Bob’s X-Ray. Our ABAC decision engine will base its decision on an elaborate ABAC policy (labeled Policies in the figure). The first policy check, Rule1, is that the action being taken is ‘View.’ The next extended requirement for Rule1 is that the company is not in ‘Emergency Mode,’ i.e., in the middle of a crisis. However, to further extend the rule flexibility during a crisis, some roles may be granted additional permissions to enable those who would typically not be permitted to perform those activities to assist. The next check is only to allow ‘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 encountered with implementing policies like this is the information needs to be obtained and evaluated at runtime. In the above policy example, if we needed to know if the user’s nationality was Swiss, then this information would likely reside in either the corporate Active Directory or HR system (Figure 3). Moreover, if we needed to know if the company was in Emergency Mode or not, this essential information might be difficult to obtain in a live corporate environment. Likewise, if we needed to ascertain their out of office status, this would reside in a corporate email system such as Office 365. Furthermore, to attain information for network login sessions or the MFA status would require a query to an Identity Provider such as Ping Federate.

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

It is easy to see that the information required to make a decision at runtime will be scattered across many different systems. With regards to your organization, if your ABAC system were to make a live call to retrieve this information from these systems, there are two prime questions:

how long would it take?
would this delay be acceptable to your organization and its users?

For end-user applications, where an additional delay of even half a second can be considered unacceptable, such a lag is not only unacceptable but also presents an insurmountable challenge. (This also assumes that all these systems present an API that can be called to retrieve this data, which many do not.) It quickly becomes apparent that our extremely powerful but complex demo policy would be an impossibility in a real-world environment and is a puzzle that organizations need to solve.

With ABAC, a challenge is that the Just-In-Time (JIT) evaluations of its rules often results in a disconnect or lack of an auditable link between the rule-based policies and the resources they protect. With access rules defined in text-based policies, ABAC policies are inherently non-relational. This model contrasts significantly with the relational nature of RBAC, where users are related to roles and 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, though answering the following standard questions should be straightforward, the reality is otherwise:

As an application owner, how would 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 how to research all the source information?
Given that the 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? With ABAC, no relationship exists between the group and the access it gives, as there would be with an RBAC model.
As an auditor, how would I audit how access is granted to the application and who is giving the access?
In a policy example with multiple unrelated checks, was the person who assigned the person’s Job Title in HR the grantor of the access or was it the person who flagged the user as having completed training?
What security weight should be associated with the Job Title and Training Status fields on a user?
From how many sources could this information be edited and by whom? Potentially many people could be unintentionally performing “Entitlement Management” on a day-to-day basis.
How does an auditor monitor the transitions when users are granted and revoked access to sensitive applications dynamically? No log would track persons who had access on a Monday versus a Friday because access would only be evaluated at runtime.

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. To successfully determine access, not only might a considerable number of rules need to be executed, but they must also be done in the same order in which the system applies them. As a result, this could make it impossible to assess risk exposure for any given employee position.
In a comparable manner to how a “Role Explosion” can occur with RBAC, an explosion can also occur with ABAC where a system with N number of attributes would have 2N possible rule combinations.
Unless rules are kept extremely simple and do not access data from various source systems, ABAC systems with complex rules from multiple attribute sources can be unacceptably slow to answer authorization queries.

ABAC Challenges

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

Another challenge with ABAC is finding someone within the organization with the skills and knowledge to write authorization policies. To write rich, accurate, and effective policies requires both solid business knowledge and a deep understanding of security. XACML was developed 18 years ago as a standards-based language built on XML to write authorization policies. The original idea with XACML was that business users would author these policies and, in vendor marketing and some analyst circles, this idea persists to this day. The notion that business users would know best how to determine who should be able to do what from a business activity perspective is, after all, entirely logical. However, writing XACML policies is extremely complex. and most business users simply do not possess the time to write IT policies.

EmpowerID Admin Guide 22