Attribute-based access control (ABAC), also referred to as policy-based access control (PBAC) or claims-based access control (CBAC), is an authorization methodology that sets and enforces policies based on characteristics, such as department, location, manager, and time of day. Using Boolean logic, ABAC creates access rules with if-then statements that define the user, request, resource, and action. For example, if the requester is a salesperson, they are granted read-write access to the customer relationship management (CRM) solution, as opposed to an administrator who is only granted view privileges to create a report. 

With account-based access control, dynamic, context-aware security can be provided to meet increasingly complex IT requirements. Use cases for ABAC include: 

  • Protecting data, network devices, cloud services, and IT resources from unauthorized users or actions     
  • Securing microservices / application programming interfaces (APIs) to prevent exposure of sensitive transactions   
  • Enabling dynamic network firewall controls by allowing policy decisions to be made on a per-user basis 

Components of ABAC

Attributes are the characteristics or values of components that are used in an access event.  These attributes can be drawn from several data sources, including identity and access management (IAM) systems, enterprise resource planning (ERP) systems, employee information from an internal human resources system, customer information from a CRM, and from lightweight directory access protocol (LDAP) servers. 

Attribute-based access control allows the use of multiple attributes for authorization to provide a more granular approach to access control, for example, Separation of Duties (SOD).

See how administrators can quickly develop policies to reduce risk of fraud and maintain compliance.

Characteristics that can be used when making a determination to grant or deny access include the following. 

Subject or user attributes

Subject or user attributes describe who is attempting to obtain access to a resource in order to perform an action. These can include username, age, job title, citizenship, user ID, department and company affiliation, security clearance, management level, and other identifying criteria. ABAC systems can collect this information from authentication tokens used during login, or it can be pulled from a database or system (e.g., an LDAP, HR system). 

Object or resource attributes

Object or resource attributes encompass characteristics of an object or resource (e.g., file, application, server, API) that has received a request for access. Examples of object or resource attributes are creation date, last updated, author, owner, file name, file type, and data sensitivity. 

Environmental or context attributes

Environmental attributes indicate the broader context of access requests. Environmental attributes can be a variety of contextual items, such as the time and location of an access attempt, the subject’s device type, communication protocol, authentication strength, the subject’s normal behavior patterns, the number of transactions already made in the past 24 hours, or even relationship with a third party. 

Action attributes

Action attributes indicate how a user wants to engage with a resource. Examples of common action attributes in access requests are view, read, write, copy, edit, transfer, delete, or approve. These can be used individually or in combination for more complex scenarios. 

Subject or User Attributes Object or Resource Attributes Environmental or Context Attributes Action Attributes 
Clearance 
Department 
Employee ID 
Job Title 
Username 
Author/Owner 
Classification 
Date Created 
Last Updated 
Type 
Current Day 
Current Time 
Device 
Location 
Time Zone 
Delete 
Read 
Transfer 
View 
Write 

How attribute-based access control works 

ABAC grants permissions according to who a user is rather than what they do, which allows for granular controls. Attributes are analyzed to assess how they interact in an environment; then, rules are enforced based on relationships.  

Here is how the process typically works:

  1. An access request is made. 
  2. The attribute-based access control tool scans attributes to determine if they match existing policies.  
  3. Based on the result of the ABAC tool’s analysis, permission is granted or denied. 

Benefits of ABAC

The attribute-based access control authorization model has unique capabilities that provide powerful benefits to organizations, including the following. 

Broad range of policies

Virtually any kind of policy can be created as ABAC’s only limitations are the attributes and the conditions the computational language can express. 

Attribute-based access control allows situational variables to be controlled to help policy-makers implement granular access.

It also enables administrators to use smart access restrictions that provide context for intelligent security, privacy, and compliance decisions. For instance, one group of employees may only have access to some types of information at certain times or only in a particular location. 

Easy to use 

Attribute-based access control is very user-intuitive. It hides technical permission sets behind an easy-to-use interface. Anyone with the right permissions can update a user profile and be assured that the user will have the access they need as long as their attributes are up to date. In addition, the maximum number of users can be granted access to the maximum available resources without administrators having to specify relationships between each user and object. 

Fast onboarding of new users

ABAC models expedite the onboarding of new staff and external partners by allowing administrators and object owners to create policies and assign attributes that give new users access to resources. With attribute-based access control, existing rules or object characteristics do not need to be changed to grant this access.  

Flexibility

With ABAC, almost any attribute can be represented and automatically changed based on contextual factors, such as which applications and types of data users can access, what transactions they can submit, and the operations they can perform.   

Regulatory compliance

The increased security provided by attribute-based access control’s granular permissions and controls helps organizations meet compliance requirements for safeguarding personally identifiable information (PII) and other sensitive data set forth in legislation and rules (e.g., Health Insurance Portability and Accountability Act (HIPAA), General Data Protection Regulation (GDPR), Payment Card Industry Data Security Standard (PCI DSS)). 

Scalability

Once ABAC has been set up, administrators can copy and reuse attributes for similar components and user positions, which simplifies policy maintenance and new user onboarding. 

Challenges of attribute-based access control

Once it has been deployed, ABAC is simple to scale and integrate into security programs, but getting started takes some effort. While most agree that the benefits of ABAC far outweigh the challenges, there is one that should be considered—implementation complexity. This is because administrators must: 

  • Assign attributes to every component. 
  • Create a central policy engine to determine what attributes are allowed to do, based on various conditions (i.e., if X, then Y). 
  • Define all attributes. 
  • Gauge the permissions available to specific users before all attributes and rules are in place.  
  • Map authorization policies to create a comprehensive policy set to govern access. 

ABAC vs RBAC

Attribute-based access control and role-based access control are both access management methods. Unlike ABAC, RBAC grants access based on flat or hierarchical roles. With RBAC, roles act as a set of entitlements or permissions. 

ABAC RBAC 
Existing roles extended with attributes and policies (e.g., the relevant actions and resource characteristics, the location, time, how the request is made). Each user is assigned a role
Authorization based on intelligent decisions. Authorization only considers the role and associated privileges 
Policies are based on individual attributes, consist of natural language, and include context Access is granted only by roles 
Administrators can add, remove, and reorganize attributes without rewriting the policy New roles must be manually defined   
Access is fine-grained Broad access is granted across the enterprise 

Choosing between ABAC and RBAC

Whether attribute-based access control or role-based access control is the right choice depends on the enterprise’s size, budget, and security needs. Size plays a big part in the choice as ABAC’s initial implementation is cumbersome and resource-intensive. 

ABAC RBAC 
Resources to support a complex implementation process Need access controls, but lack resources for a complex implementation process 
A large number of users with dynamic roles Well-defined groups within the organization 
Large organization with consistent growth Organizational growth not expected to be substantial  
Workforce that is geographically distributed Workforce that is centrally located 
Need for deep, specific access control capabilities Comfortable with broad access control policies 

ABAC and RBAC: A hybrid approach

Attribute-based access control and role-based access control can be used in conjunction to benefit from RBAC’s ease of policy administration with the flexible policy specifications and dynamic decision-making capabilities of ABAC. Using ABAC and RBAC (ARBAC) can provide powerful security and optimize IT resources. 

The ARBAC hybrid approach allows IT administrators to automate basic access and gives operations teams the ability to provide additional access to specific users through roles that align with the business structure. By making roles attribute-dependent, limitations can be applied to specific users automatically without searching or configurations.

This streamlines access assignments and minimizes the number of user profiles that need to be managed. With ARBAC, IT teams can essentially outsource the workload of onboarding and offboarding users to the decision-makers in the business. 

For example, ARBAC can be used to enforce access control based on specific attributes with discretionary access control through profile-based job functions that are based on users’ roles. ARBAC can also be to support a risk-adaptable access control model with mutually exclusive privileges granted such that they enable the segregation of duties. 

Support organizational security with ABAC

Attribute-based access control has become widely accepted as the authorization model of choice for many organizations. Not only is it incredibly powerful, but it eases part of the security administration burden.  

Take control of your cloud platform.

Learn more about SailPoint and Access Modeling.

Get Started Today