This article provides foundational knowledge about the authorization aspect of identity and access management (IAM). Its goal is to introduce access control models commonly used today, with a deeper exploration of the Attribute Based Access Control model (ABAC). This model is having traction in the industry, but is often misunderstood.

Before we start, here are key concepts referenced throughout the article.

Subject

The entity that accesses an object. The subject can be, for instance, a user or an automatic process.

Object

The resource that is being accessed. Examples include a file in an operating system, a field in a person’s record, an API, etc.

Access control models

This section covers the main access control models that can be encountered in authorization solutions.

Access control list (ACL)

This access control model is one of the earliest introduced. The first implementation of this model dates back to 1965 with the Multics operating system.

In this model, the owner of a resource maintains a list of which subject (such as users, or accounts) that can access its resource and what actions they are permitted to perform.

This model is used in various contexts. For instance, in an operating system, a file is associated with a list of subjects that can read, modify or delete them. In an LDAP directory, an ACL defines how a subject can interact with objects in the directory.

Role-based access control (RBAC)

This model, developed by NIST researchers in 1992, introduces a key distinction from the ACL model by breaking the direct relationship between subjects and objects.

In the RBAC model, permissions are not directly assigned to subjects. Instead, subjects are assigned to roles, and these roles are granted permissions to access specific objects.

These roles can represent many concepts like the subject’s business function or its department. A role can be used to group subjects and privileges together, simplifying their management. However, in practice, most organizations face a “role explosion” situation where a multitude of distinct roles is created to account for every exception or nuance in privileges. This situation makes role management a complex task.

Attribute based access control (ABAC)

ABAC can be considered as a more flexible generalization of the RBAC model. In RBAC, a subject’s privileges over an object are determined by its assigned roles. In contrast, with the ABAC model, the privileges can depend on any of the subject’s attributes, not only its role. Examples of such attributes can include the subject’s business unit, its seniority level in an organization, its security clearance level, etc.

The ABAC model also incorporates object’s attributes and contextual attributes. An object’s attributes define the resources that can be accessed and contextual attributes define the context in which an authorization request is performed. These three levels of attributes allow for complex and flexible policy. For instance, such a policy could be:

A bank employee working at the Montréal branch can access a VIP client’s bank accounts, only during office hours and only if the request is made from within North-America.

Note that we consider ABAC and Policy-based access control (PBAC) as synonymous. PBAC is sometimes used as a more business friendly termmarketing term for solutions that effectively implement the ABAC model. Both ABAC and PBAC solutions implement a model which allows the creation of authorization policies based on subjects, objects and contextual attributes.

Relationship based access control (ReBAC)

The idea of an authorization model based on relationships was first discussed in 2006 in the context of information sharing in social networks. An application for this model is to allow an individual to share various pieces of information to other individuals based on their relationship.

The ReBAC model is similar to ABAC in that both can define complex and fine-grained authorization policies. The main difference in the two models lies in how the policies are designed and evaluated. In ABAC model, a subject’s, object’s and contextual attributes are evaluated. In the ReBAC model, what is evaluated is the relationship between the subject and the object.

For instance, in the ReBAC model, a document object could have an editor relationship to a specific subject. If that subject attempts to edit the document, the ReBAC system validates that the editor relationship exists between the subject and the object. If no such relationship is found, the edit request is denied.

ABAC model

This section focuses on the architecture and components of the ABAC model.

ABAC architecture

The various components of an ABAC architecture were originally defined as part of the AAA Authorization Framework RFC (RFC 2904) published in 2000. This RFC established foundations of distributed policies which are now used in modern ABAC solutions.

A flow for a request follows the following steps:

1. A request is made to a system for an object (resource), such as retrieving records in a database or calling an API. This request is intercepted by the Policy Enforcement Point (PEP) which is usually part of the system that returns the request’s response. The PEP can take many forms: a database plugin, a sidecar to a service mesh, code integrated within the application, etc.
2. The PEP forwards the request to the Policy Decision Point (PDP). The PDP is responsible for making the authorization decision. The PEP may also provide additional relevant information that was not included in the original request. This additional information can be application specific or contextual information in which the request was performed. The PDP is a component that can easily be centralized and potentially deployed in the cloud. A valid deployment strategy is to have many PEPs deployed in on-premises business applications. All these PEPs can then reach out to a single PDP deployed in the cloud.
3. The PDP may rely on additional data sources to make an authorization decision. This is necessary when the PDP doesn’t have enough information with the authorization request itself and additional information that is provided by the PEP. When the PDP needs additional information, it can query one or many Policy Information Point (PIP). A PIP is a component that connects to various data sources (databases, LDAP, etc.) in order to provide information to the PDP so that the PDP can perform the authorization decision. The information provided by a PIP can be related to the subject making the request or the object that the subject wants to access.
4. Once the PDP has all the necessary information, it evaluates relevant policies in order to perform an authorization decision.
5. The PDP then returns the authorization decision to the PEP. The PEP is in charge of enforcing that decision. 
6. The PEP enforces the authorization decision. This enforcement step is highly dependent on the implementation and the object that is being accessed by the subject. For instance, if a subject wants to do a GET on an API endpoint, the PEP could grant or deny the request. If a subject wants to do a SELECT SQL query on a database, the PEP could filter the rows and columns which the subject has access to.
7. If access is granted to the subject, the PEP returns the requested object.

In parallel to the request made by subjects to objects, administration tasks are also performed in the system.

1. An administrator uses the Policy Administration Point (PAP) to manage the various policies in the system. Like the PDP, the PAP is a component that can easily be centralized. The PAP, PDP and the policies managed and read by these two components can be deployed in a central location.
2. The PAP updates the policies that are read by the PDP when the PDP performs its policy evaluation task.

ABAC access control policies and best practices

Policy format

Policies in the ABAC model follow the format:

Here is the breakdown of the various elements of a policy:

Who

The subject making a request. The subject can represent a user account, an employee, a client, a non human system, etc.

What

The object or resource being accessed. A resource can be an API endpoint endpoint, a column in a database, a microservice, etc. The what portion of a policy also describes the actions that can be done on the object. For instance, the what portion of the policy can specify that a given subject can perform a GET on an API endpoint to retrieve a document, but cannot perform a POST on that same API endpoint on that same document.

When

The context in which the request can be performed. Contextual factors can include the time and date at which the request is performed, the geolocation from where the request originates or any other contextual information that the PEP can provide to the PDP when requesting a policy evaluation.

Policy creation best practices

At a high level, the process of creating an ABAC policy follows these steps:

1. Define assets and resources to protect. In the ABAC model, these would be the objects to protect and would represent the what of the policies that are being designed. It is a good practice to start by defining objects rather than subjects. Defining subjects first can lead to irrelevant or overlapping subjects definitions.
2. Identify the various objects’ attributes that are relevant when performing an authorization decision. It is also important to identify the source of these attributes. The source could be in the request itself, it could come from a PEP or the attribute could be stored in a PIP.
3. Identify the actions and usage patterns for the various objects. This includes the design and implementation of authorization with user journey focus that considers authentication infrastructure and data dependencies inherent to the security ecosystem protecting access to objects.
4. Once the objects’ actions and usage patterns are defined, define which subjects should be able to perform them.
5. Identify the subjects’ attributes that can be used to properly identify them. Just like it was done for the objects’ attributes, it is also important to determine the source of the subjects’ attributes (the request, additional information by the PEP or PIP).
6. Identify any additional contextual attributes that should be taken into consideration when a subject performs an action on an object. Examples of additional contextual information could include: only during business hours, only when in North-America, etc.
7. After gathering all necessary data it is possible to put all of this together to design proper ABAC policies. To do that, identify control points between users and resources where context and attribute data intersect with sufficient information to make effective authorization decisions.

Policy design principles

Here are some design principles that should be taken into consideration when creating policies. Not all of these principles are applicable to every context, but it is a good practice to keep them in mind.

• Additive: New rules and attributes add to, rather than replace, existing ones.
• Encapsulation: rules are encapsulated within their own layer or module. Changes in one adopter’s advanced rules don’t affect others’ implementations.
• Shared foundation: Build upon a consistent common foundation without altering it.
• Backward compatibility: Utilize base level authorization if advanced layers are not serviceable.
• Gradual adoption: Introduce advanced capabilities at self-pace as use-case/requirements mature.
• Fallback mechanism: If an advanced rule fails or is inapplicable, the system can fall back to more basic rules. Ensures continued operation even if some advanced components are compromised.

Conclusion

Hopefully, this article has helped solidify your understanding of authorization’s basic concepts and more specifically, the ABAC authorization model.

In systems with advanced access control use cases and requirements, understanding the details of advanced access control models is essential. This article should have given you the high level understanding necessary to implement more complex authorization controls in your projects.