What is Attribute Based Access Control?

Introduction

This paper looks at the history of access control and explains why Attribute Based Access Control has become the standard authorization model at organizations that need to both secure and share information assets.

The essay uses easy-to-understand examples to show the strengths and weaknesses of different authorization models. It then goes on to explain how ABAC can overcome legacy authorization issues to provide a robust, flexible and fine-grained solution to the access control challenges faced by today's organizations. The paper also looks at the ABAC architecture and details the key elements of the ABAC solution. Finally, it discusses the importance of policies and how they can be used to satisfy strict internal controls and regulations.

Access Control

Let's begin by answering the question: What is access control? Access control is the act of controlling access to anything. Controlling access to physical locations such as a room, for instance. Or controlling access to documents online. Or controlling access to secret formulas and trade secrets. Access control has been around as long as people have had the need to share their resources selectively.

Access Control Lists

Typically access control relies on verifying someone's identity. For instance, most probably you will only let a family member, or someone you know, into your home. You know the identity of the person and so grant them access to your home accordingly. In the software world, identity is also commonly used as a basis for granting access. When we control access based on user identity, we typically talk about access control lists (ACL). Many content management systems use multiple ACLs to determine who can gain access to a given context.

ACLs are lists of user identities/names (e.g., Alice, Bob, Carol) that are associated with a resource that can be accessed. Imagine a school where the chemistry lab has an ACL containing the names Alice and Bob. Such a list can be augmented with actions. Alice can enter the lab but not leave it. Bob can both enter and leave the lab. In this case, the ACL would be composed of both a username and an action.

ACLs are simple and straightforward, but they are limited in terms of scale, management, flexibility and expressiveness. How, for example, would you define an access control list for an entire school? What if the school had 1,000 students, 100 teachers, additional staff members, numerous resources, and an array of possible actions these actors could perform? Suddenly this simple access control model is no longer so simple.

The problem with ACLs is that they are one-dimensional. Their simplicity fails to address the complex needs of today's organizations.

Role-Based Access Control (RBAC)

Rather than focusing on identities, let's consider a different organizing principle: roles. An individual associated with a school could be a student, a teacher, or a member of the non-teaching staff (a nurse, an administrator, a food service worker). These are all roles. Using this principle, we can start organizing our access control based on user roles and the permissions associated with those roles. Teachers, for example, can issue grades. They can enter the teachers' lounge. Students can use the cafeteria while nurses can enter the school clinic.

Role-Based Access Control (RBAC) was first defined in a seminal paper in 1992. RBAC was soon standardized by the National Institute of Standards & Technology and quickly became the de facto standard for access control. This model works extremely well with a medium-sized user base, a small number of applications, and simple access control challenges. RBAC starts to fail when the number of access control use cases grows beyond a given point and becomes unmanageable. This leads to a problem the IT security world has dubbed "role explosion".

Role Explosion

Imagine for instance that a school wants to make sure students can only access classrooms that are relevant to their grade or school year. Imagine further that a teacher can only enter a classroom associated with their department, and that students can become teaching assistants. To manage these requirements, we would need a new role for every year, class, and department. And the more departments and years there are, the greater the number of roles required. This is why many organizations using RBAC experience what's called "role explosion". The tendency is for the number of roles to increase--along with their associated permissions--to the point where the system becomes impossible to manage.

Segregation of Duty (SoD)

Role explosion is not the only major challenge faced by RBAC users. Another involves segregation of duty. Banks, for instance, do not want traders approving the transactions they have initiated. And returning to our school example from above, we would not want students to be able to edit student grades. But what about students serving as teaching assistants? We might want them to be able to edit other students' grades, but not their own.

In RBAC terms, teaching assistants would have two roles: that of a student and that of a teaching assistant. But assuming students can view their own grades and that teaching assistants can edit student grades, a person with both roles could potentially edit his or her own grades.

To prevent teaching assistants from editing their own grades, we need to ensure that there is a Segregation of Duty (SoD) in place. Unfortunately, RBAC doesn't have a mechanism for implementing SoD in this sort of common, real-world example. We could try to work around the problem by making sure students are never made teaching assistants or we could remove the "edit grade" action from the teaching assistant role. But this would force us to alter our requirements for the sake of our access control system's limitations.

Outgrowing RBAC

What if we could express access control not only in terms of roles and permissions but also in terms of additional parameters such as "year," "department," and "permissions"? What if we could express a relationship between an actor and a targeted object? Such an access control model would be truly multi-dimensional, and this is where Attribute Based Access Control is a perfect fit. What if we could use contextual information, e.g: time of day, risk score, etc...

Attribute Based Access Control (ABAC)

Role, department, and year are examples of attributes. An attribute is a piece of information that can be used to describe someone or something. An attribute is typically a key-value pair, meaning that attributes come in sets: an identifier (or key) and the value or values identified with it. The attribute identified as "role" could, for example, have values such as "art teacher," "teaching assistant," "nurse," etc.

We referred to RBAC as being two-dimensional because it focuses exclusively on user roles and permissions. ABAC has the ability to employ user attributes, action attributes, context attributes (such as time, device, and location) and many more. The fact that we can use attributes that describe virtually anything makes ABAC multi-dimensional.

Policies

Attributes alone, though, are not enough. Let's say you are a teacher in the arts department. How do we implement your authorization requirements based on those attributes? We need a mechanism that will allow us to do that.

In ABAC we use a policy language called the eXtensible Access Control Markup Language (XACML). Using this language, we can combine attributes in order to implement our policy requirements.

Say for example we have the requirement "Teachers can view student grades." XACML allows us to take this sentence and translate it into attribute categories. These categories represent the grammatical function of the attribute in the authorization requirement.

Requirement: Teachers can view student grades.

The word in red represents the subject while the word in green, the verb, denotes the action. Finally, the words in blue represent the object or resource targeted for access.

In terms of attributes, the requirement is:

Users with role = teacher
Can do the action = view
On object type = grade

Using XACML, policies can be written to satisfy extremely complex requirements. For this reason, some have dubbed ABAC "policy-based access control." XACML policies help to make ABAC extremely flexible and expressive to both share and lock down access as conditions dictate.

Policies Enable Relationships

One of the key aspects of ABAC is its ability to implement relationships. ABAC is multi-dimensional in that it can utilize attributes that describe the user, the resource, the action, and the context. When we have attributes of the user and attributes of the resource, we can then relate them together.

Let's return to the policy requirement allowing teachers to view student grades. What if we wanted to ensure that teachers could only view the grades of those students attending their course?

Requirement: Teachers can view the grades of those students attending their course.

Broken down into attributes, the requirement becomes:

Users with role = teacher
Can do the action = view
On object type = grade
If grade.course.teacher = user.userId

The conditional expression at the end denotes a relationship. From the grade a student has received, we look at the course for which the student received the grade. From the course, we determine who was the teacher of that class. We compare that teacher's identity to the identity of the individual trying to view the grade. If there is a match, that teacher can view the grade.

This ability of ABAC to implement relationships makes it far more flexible than RBAC and provides more fine-grained access than RBAC ever could. The use of relationships helps to avoid role explosion and allows for truly fine-grained access control.

Policies Scale Better

Another area in which ABAC outperforms RBAC is in scalability. The use of policies allows ABAC to scale effortlessly where scaling RBAC is cumbersome and labor-intensive.

Imagine we have a requirement that teachers in the art department can enter classrooms in the art department.

Requirement: Teachers in the art department can enter classrooms in the art department

In terms of attributes, the requirement can be rendered as follows:

Users with role = teacher
Can do the action = enter
On object type = classroom
If teacher.department = classroom.department

Note that the implementation is abstracted away from any particular department. This means the policy will work regardless of the department. As a result, it will work equally well whether we are talking about the math, science, biology, or art department. It will even work for a new language department the principal is slated to launch next semester. In ABAC, you only need one policy to provide for all these possibilities whereas in RBAC you would need to implement, manage, provision, and de-provision numerous new roles.

In short, ABAC scales better because policies scale better. It reduces the management burden and also makes sure the right access control checks are applied consistently to all entities in the system.

With policies, the provisioning and de-provisioning process is made much simpler. In RBAC, you are constantly having to add or remove roles and/or permissions from users. In ABAC, the user's attributes are used directly, which greatly simplifies this process since we no longer need to worry about granting or removing user permissions as this is taken care of automatically.

Policies Enable Dynamic Segregation of Duty

We have seen that ABAC enables relationships and that relationships improve scalability. Now we will look at how relationships help to eliminate violations of Segregation of Duty, also known as toxic combinations. To illustrate this point, let's go back to our teaching assistant example.

The original requirements were:

Teaching assistants can modify students' grades.
Teaching assistants cannot modify their own grades.

In an RBAC setting, we would be unable to satisfy the combination of the two requirements because we would be limited to a static form of segregation of duty. In other words, we could grant a teacher the ability to modify student grades and we could grant students the right to view their own grades. As students, teaching assistants would not be able to modify their own grades, or those of anyone else. This would prevent the teaching assistants from tampering with their own grades but it would also prevent them from performing one of their required functions: modifying other students' grades.

Because teaching assistants are both students and teaching assistants at the same time, requirements like those above lead to a toxic combination. RBAC cannot resolve such a dilemma. But ABAC can, by employing yet another type of relationship.

Users with the role = teaching assistant
Can do the action = modify
On object type = grade
If grade.student.name != user.userId

In this case, a user who is a teaching assistant can modify a student grade unless the user is the student in question. This relationship implements segregation of duty check and avoids any toxic combination. Students can now become teaching assistants and carry out grading tasks but they cannot modify their own grades. Mission accomplished!

Policies Can Address Different Scopes

ABAC provides a unified, consistent, and coherent way of addressing different access control concerns across an entire enterprise. For every department or user, the same tooling and language is used to express access control requirements, namely, attributes and policies.

Consequently, different parties within an organization can create access control policies to address their own concerns. This means that the head janitor can define specific policies, as can the principal or various student groups. This is possible because policies can be made to address different scopes or concerns.

For instance, the head janitor may want to define when staff and students may enter the school grounds:

Deny teachers and students access to school grounds between 10pm and 6am.

The principal may want to deny access to students that have been expelled:

Deny expelled students access to school grounds and school resources.

The principal may also want to implement a chewing gum ban:

Deny access to anyone chewing gum.

Chemistry teachers may want to limit access to the lab supply room to only a few trusted students:

Allow a student access to the lab supply room if the student's name is on the trusted student list.

These requirements introduce a variety of policy authors. We have global rules (such as the chewing gum ban) and specific rules (such as the chemistry lab rule that only applies to the chemistry department). ABAC can accommodate these different authors and their different concerns of various scope. It can even work out conflicts between policies since it allows us to define policy priorities.

Policies Bridge the Gap Between the Business and IT

RBAC has traditionally been in the hands of IT and more specifically the IAM (Identity Access Management) team. The rise in the number of applications, data, and users, has led to IAM teams creating ever-increasing numbers of roles and permissions. This has led to roles and permissions with complex names and obscure meanings like "teacher_ dept123_lab1".

Because ABAC is policy-based and because policies use natural attributes such as user role, department and date of birth, the policies themselves are a direct reflection of the original requirement. The use of attributes allows the requirement to map directly into the policy. This provides several benefits. Policies are relatively easy to maintain. They make it possible to verify authorization policy coverage. They can be efficiently audited and compliance can be effectively proven.

Externalized Authorization

What is externalized authorization?

The ABAC model provides externalized authorization by leveraging the principle that software code should be decoupled based on the function it serves. Instead of delivering a single application that implements all the features that are required, the software developer simply implements core business functionality and reuses common blocks for nonfunctional aspects such as authentication, logging, and data storage.

These non-functional aspects can then be effectively externalized. No one would dream of re-implementing authentication.

The same applies to authorization. Why should application developers have to rewrite authorization for each application? Why can't applications simply reach out to an external authorization server as they do for authentication? ABAC addresses these challenges and meets them.

Existing frameworks

ABAC did not invent externalized authorization. The term Externalized Authorization is used by Gartner to describe the space ABAC lives in. Other analyst firms e.g. Kuppinger Cole called this space Dynamic Authorization Management.

Many frameworks have strived to externalize authorization in the past. Such frameworks include:

The Java Authentication and Authorization Service, or JAAS is the Java implementation of the standard Pluggable Authentication Module (PAM) information security framework.
Spring Security (Java)
Microsoft Claims

There are many more frameworks in different layers (application layer, data layer…) that are being used to externalize authorization. While these frameworks are a great way forward in terms of externalizing authorization and making it more manageable, they still suffer from several issues:

The frameworks are technology-specific i.e. they require subject-matter expertise
They only work for a given set of applications e.g.:NET
The frameworks are typically only role-based
The frameworks are seldom policy-based

ABAC enables externalized authorization by:

Providing a standard architecture
Providing a standard authorization policy language
Providing a standard mechanism for querying authorization decisions

What is externalized authorization?

In ABAC, authorization is no longer implemented in code but rather using policies in XACML, a standard policy language. XACML is rich enough to define many different scenarios--from simple, role-based access control use cases to access control lists to relationship-based and risk-aware access control. It uses attributes of the user, the resource, the action, and the environment.

Policies are defined, authored, managed, and versioned centrally at a central point of management. They can be run centrally or distributed for local decision-making or enforcement.

Because policies are managed outside the application being protected, they can evolve independent of the application code. This makes it easier to adapt the application to new scenarios and authorization requirements.

The key components are:

Policy Enforcement Point (PEP): the PEP is responsible for protecting the application. It intercepts the business flow between the client and the application, converts the business request (View record #123) into an authorization request (Can Alice view record 123?) and sends it off to the PDP. When it receives a response back from the PDP, it enforces it, that is, it lets the original business request go through to the backend application or it bounces it back to the client. The PEP's form factor depends on the nature of the application being protected. For instance, you might use an API gateway to protect APIs and microservices. You could use an IIS filter to protect .NET web applications.
Policy Decision Point (PDP): the PDP is at the center of the architecture. It is the brain or engine that processes the incoming request and evaluates it against the authorization policies it has been configured with. It eventually produces a decision that it sends back to the PEP. In the process of evaluating policies and producing a decision, it may turn to policy information points (PIP) to retrieve additional attribute values for needed attributes such as a user's department or role.
Policy Information Point (PIP): a PIP is the driver that connects the PDP to underlying sources of attributes. These sources can be LDAP, databases, web services, and more. The sources contain metadata about the user or the resource. Examples include the user's role, department, date of birth, and clearance, as well as the resource's classification, department, and amount (in the case of a transaction). A PDP can use several PIPs at the same time to retrieve several attribute values.
Policy Administration Point (PAP): the PAP is the tool through which administrators create, manage, and edit authorization policies. The policies are then deployed to the PDP.

Central Point of Management

The architecture, with a single Policy Administration Point (PAP), enables externalization and centralization of the policies and configuration. It makes the system easier to manage and more scalable. It also makes it possible to centrally manage all the Policy Decision Points (PDP). This is an improvement from existing authorization systems that come with their own management portals, as these make the system difficult and time-consuming to manage as well as hard to keep in sync.

The fact that Policy Decision Points are centrally managed means they can be deployed in a variety of ways. For instance PDPs can be installed as a central enterprise authorization service, or they can be located with the application they are protecting. This can enhance the performance of the system.

ABAC follows the architecture defined in the XACML standard and depicted in the graphics below.

Scalable Authorization

Because the Policy Decision Point is stateless, several PDPs can be deployed to increase the load and throughput. To this end, administrators can deploy PDPs behind a load balancer and distribute traffic accordingly. This means it is possible to grow the authorization capacity linearly with the growth in demand.

Standardized Request / Response Process

One of the key benefits of ABAC is that it standardizes the way authorization is queried. Unlike other existing frameworks (Spring, claims-based, etc.), which have different ways of querying their own authorization engines, the ABAC authorization approach boils down to a simple "Yes" or "No" response. This applies no matter how complicated the question. The simplicity of the request/response process facilitates integration with different applications and frameworks.

ABAC also lets you have richer response flows. Although the response is always in terms of a Yes/No question, the decision can be augmented with additional statements such as:

Yes, allow + log the fact the user has been granted access. Or
No, deny + reroute the user to a two-factor authentication page.

Policy-Driven Authorization

Using policies to meet internal controls and regulations.

As mentioned earlier, ABAC is sometimes referred to as policy-based access control. It is the authorization policies of an organization that govern who can access information and the conditions under which they can do so. These make it possible for organizations to comply with strict regulations in every market in which they operate. ABAC policies are written in the XACML language. XACML can precisely replicate in a policy any regulations or internal controls to be enforced. The Policy Decision Point will then ensure requested data is protected in accordance with that policy.

Policy auditing and compliance validation.

We have already discussed role explosion and the management difficulties it presents. Using policies to externally manage authorization not only reduces the demands on administrators; it also considerably simplifies the auditing process. With the right tools auditors can get a list of the conditions under which a policy allows a user to view data, or alternatively the full set of the conditions under which the data can be viewed. This level of authorization transparency helps auditors prove compliance and allows managers to see what team members or third parties have access to.

Summary

Access control has evolved to meet the changing security challenges organizations face in the digital age. Attribute Based Access Control is quickly becoming the standard model for organizations confronted by the need for a robust and flexible solution to today's increasingly complex security demands. Unlike earlier access control models, ABAC provides a multi-dimensional system that through its use of attributes and policies prevents role explosion, increases scalability, enables relationships, eliminates Segregation of Duty conflicts, and externalizes authorization for ease of management and control. Additionally, it allows organizations to comply with an ever-growing body of regulations in an increasingly demanding regulatory environment.