Attribute-Based Access Control (ABAC)

Attribute-Based Access Control, Policy-Based Access Control, Claims-Based Access Control or the widely popular “ABAC” is an access control system or an authorization management model for Identity Access Management (IAM) in computer systems security. The National Institute of Standards and Technology (NIST) considers ABAC to be the dominant next generation technology for secure access authorization in IT systems.

This article lays out an introduction to Attribute-Based Access Control (ABAC) and unpacks the basics of implementing an ABAC model in your organization.

Access Control Before ABAC

Before ABAC became prominent in the past decade as an access control paradigm in enterprise infrastructure security, including in API, microservice, database, data, big-data, and file server security, Identity-Based Access Control (IBAC) and Role-Based Access Control (RBAC) were the norms for access authorization.

The IBAC model (examples include Discretionary Access Control, Access Control Lists, and Permission-based systems like Microsoft SharePoint) uses only the subject’s identity for access authorization. In other words, IBAC considers who can access a system resource. But identity alone is a very coarse parameter for access control, and IBAC is extremely user-centric with limitations on scalability. IBAC was more suitable for smaller environments with few users.

So the RBAC model debuted to replace the IBAC model in 1992. The RBAC model defines access control according to the subject, object, and action involved. RBAC considers who can access a system resource, what resource that user can access, and how the user can access the resource. RBAC is a more granular access control model than the IBAC, which we still use today in new application developments. However, in more complex system environments, RBAC requires lengthy role engineering, creates segregation-of-duty violations, leads to stale permissions, causes role explosion, and loses control over sensitive data at the granular level.

So then ABAC was introduced as a solution to the challenges in IBAC and RBAC systems.

What is Attribute-Based Access Control (ABAC)?

NIST defines ABAC 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.”

In simple terms, ABAC uses the information of who the user is, what the user wants to access, when and where the user wants to access it, why the user needs access, and how the user accesses it, to either grant or deny access to a system resource. Attributes define these parameters. You can think of attributes as the building blocks that create the policies. ABAC considers subject attributes, object attributes, and environmental attributes to define the action attribute or access levels (e.g., read, write, edit, delete, etc.).

Given below is a diagram that differentiates IBAC, RBAC, and ABAC in a nutshell.

 

Components of Attribute-Based Access Control System

  1. Subject – Who or What is requesting access to the system asset (object)
    Subject Attributes
    – Parameters or the identifying criteria belonging to or used to authenticate the subject
    Examples: User ID, Job Role, User Branch/Department, Group Memberships, Management Level, Security Clearance, login authentication tokens (SAML token), and any other identifying data attributes that you can collect from an HR system or a directory.


  2. Object – The system asset or the information asset that you get access to (e.g., file, server, application, API, etc.)
    Object Attributes – Parameters or the identifying criteria belonging to the object or resource
    Examples: File Name, File, File Creation Date, File Owner, data classification category, Asset ID, Attribute Metadata of a REST API


  3. Context – The environment in which the subject requests access authorization
    Environmental attributes – Parameters that define the nature of the environment (mostly about when and where) from which the user makes an access request.
    Examples: Time, Location, Client Type (PC, Mobile, etc.), communication protocol, encryption strength


  4. Action – The type of operation that the subject wants to perform on the object. Some ‘Action’ examples are view, edit, delete, etc. You may define an action sometimes with the use of multiple attributes. For example, if you want to transfer 1000 dollars to an account. Requesting ‘transfer’ action has two attributes as <action type = transfer> and <amount = $1000>.

 

Consider the following example.

Only senior managers in the HR department can view the KPI record of a management-level employee account.

Herein, all the capitalized words are attributes used to control access. “Senior manager” is the user role which is a subject attribute. “HR department” is the user location which is an environmental attribute. “View” is the action. “KPI record” is the object or the resource. “Management-Level” is the resource hierarchy, which is an object attribute. “Employee account” is the object type, which is an object attribute.

Key Characteristics of an Attribute-Based Access Control System

1/ Access authorization is externalized from the business logic

You do not need to apply access control rules at a specific defined point or to code business logic for your application. In other words, you do not need to embed access control policies into your application code. So access control rules can be maintained independently of the business logic of an application.

2/ ABAC systems have a centralized authorization model

Access control policies are maintained in one central location external to the application code. The central authorization model lets you run access control audits and access reviews easily and quickly.

3/ ABAC is a policy-driven authorization model

Authorization logic is expressed as configurable and flexible policies rather than inflexible hard codes. Policies are easier to maintain and audit because they are closer to natural language.

4/ Attribute-Based Access Control

Attributes are the building blocks of the access control policies and rules.

5/ Attribute-Based access control decisions are made dynamically at runtime

When access to a resource is required, policies are checked against the access request, a decision is made, and access will be granted or denied.

How Do You Implement Attribute-Based Access Control?

You can use the following six-step methodology to apply ABAC to any access authorization use case in an organization of any scale.

1/ Gather Authorization Requirements

As the first step, decide what authorization requirements you need to run the business logic of your system. Gather authorization requirements from the business of your organization and author them in such a way that both the IT people and businesspeople can understand the requirements.

Your authorization requirements may look like this:

  • An employee can edit a record in the draft mode.
  • A manager can view any record of his/her department.
  • A manager can update a record of an employee who is junior to his/her position.

2/ Identify required attributes

Highlight the attributes in the authored requirements. Then classify and identify the attributes based on their categories, such as resource attribute, subject attribute, and environmental attribute (following the example above).

3/ Define and write up the authorization policies using XACML

4/ Test the policies

Ask the business to define acceptance tests. Next, run acceptance tests on the defined policies to verify whether the rules actually implement the business scenarios or not. Test the policies against correctness and gap analysis.

5/ Deploy the policies to your system following the XACML Standard architecture

6/ Run Access Reviews

Review access reports regularly to verify whether the administrators are defining the correct rules, attributes, and configurations and check to ensure the policies you have written comply with the principle of Least Privilege and Segregation-of-Duties policies, and deliver for the desired use cases. You can perform PEP-PDP (Policy Enforcement Point – Policy Deployment Point) tests to review access.

What are the Pros and Cons of ABAC?

Pros of RBAC

  • An ABAC system permits both granting and denying access to system resources. The IBAC and RBAC systems can only control access on a grant privilege. But ABAC can also deny access as the policies have the power to define conditions.
  • ABAC is flexible. You can apply ABAC to APIs, databases, web services, microservices, and more by applying the same basic policy-making methodology with little administrative oversight. For example, if you want to define a new set of access policies, you can do so without defining new subject-object relationships. So administrators can modify rules and attributes and control access for changing situations within an organization with less overhead and maintenance.
  • Access policies are contextual and more fine-grained than roles and role-groups in RBAC. So access control is extremely flexible within an ABAC system.
  • The ABAC model can easily accommodate new access rules for staff changes, onboarding employees, and external users (subjects) without the need to modify existing rules and attributes.
  • ABAC systems ensure higher privacy, security, and compliance with security and data protection regulations than RBAC and IBAC systems do. The attributes and policies can secure information assets on a fine-grained basis. For example, in an RBAC system, a user on the HR team has access to all employee records. But, in an ABAC system, HR team users may not have access to some employee records based on their location and time of access (attribute-based policies). So information assets get stringent security and privacy protection in an ABAC system.

The pros of ABAC outweigh its cons. But organizations should pay close attention to the factor of implementation complexity when considering ABAC for their access control system.

Cons of RBAC

  • Taking the flight off the ground is cost and resource-intensive in an ABAC approach. You will need to define hundreds or thousands of attributes, and author and establish policies to gauge the permissions available to a particular user. But the hard work pays off because you can reuse defined policies for your future ABAC implementations of a similar nature. Once established, ABAC is flexible enough to modify and scale without much effort.

Final Words

In 2020, Gartner introduced the concept of modernized authorization architectures using ABAC as the key to reducing risk and data breaches. The Federal Information Officers Council has endorsed ABAC as a secure model for safe information sharing by organizations. These testimonials speak to the reliability of ABAC in the identity access management (IAM) space.

Ready to get started?

Subscribe to build.security’s newsletter

Keep up with the latest news on our authorization policy management platform