What is attribute-based access control?

ABAC definition

Attribute-based access control is an authorization system that relies on attributes to grant access. ABAC systems grant access to users with approved characteristics. This could include the user's role, the time of day, or even their device location.

The idea behind ABAC is to protect data and applications with granular controls. Users that fail to meet predefined conditions are denied access. Sensitive data should remain safe, while approved users can carry out their duties.

Attribute-based controls emerged as an alternative to role-based control (RBAC). ABAC offers more flexibility and allows dynamic calibration in rapidly changing environments. It enables granular management of user access to critical resources. This matters in a world of cybersecurity threats and costly data breaches.

This article will cover:

• How attribute-based access controls work
• The main components of an ABAC solution
• The advantages of using attributes to manage access
• A detailed comparison between ABAC and role-based access control to help you choose the right access control solution.

ABAC components

Various attributes can be embedded into access policies using XACML code. This functionality empowers administrators to tailor security settings for distinct applications, data sets, user groups, or geographical areas.

Controls generally fall into four categories: subjects, resources, actions, and environmental attributes.

1. Subject attributes

In an ABAC system, the subject is the user who makes an access request or seeks to carry out an action. Subjects can be identified in various ways:

• Unique IDs and job roles.
• Membership of a specific user group.
• Seniority level or departmental membership.
• Security clearance.

Personal user attributes are usually drawn from directories maintained by HR departments. ABAC systems take existing HR data and use it to apply controls about who can access data, and what they can do when they gain access.

ABAC systems can also use authentication tokens to gather user attributes. This can be a useful method to verify and authorize remote workers connecting to sensitive company assets.

2. Resource attributes

Resource attributes refer to the objects that users seek to access. This includes applications, servers, APIs, and individual files. Relevant attributes vary but might include file creation dates, modification dates, file types, and the asset's sensitivity rating.

These characteristics allow administrators to set granular attribute-based controls to protect databases or apps. For example, security teams could restrict access to medical records to doctors who are on-site and attached to an individual department.

3. Actions

Actions refer to ways that users interact with network resources. These attributes vary between settings. However, common action attributes include read, write, delete, save, and transfer. These core actions cover most of the actions that put data at risk.

With ABAC in place, administrators can limit data misuse. Admins can define which actions individuals can carry out. They can set permissible contexts and even allow actions at specific times or places.

4. Environmental attributes

Environmental attributes are pieces of information about the context in which access events take place. Common attributes include the time of day, the device location, the time zone, and the device type.

Setting environmental attribute values has many advantages. For example, limiting access to users in the nearby area makes it harder for attackers to gain access from other regions. This applies even if attackers have obtained legitimate credentials.

Environmental attributes can also include a historical component. Access controls can log user activity from previous sessions and detect whether the user is behaving unusually. This adds another layer of security at the highest sensitivity levels.

The attribute types listed above do not work separately. In practice, smart access restrictions include many attributes for each resource. By combining different attributes, security teams can control who accesses important data without making life harder for legitimate users.

How attribute-based access control works

ABAC systems allow access if the user possesses the correct attributes. The system compares user profiles with attribute-based access control policies. This is why ABAC is also known as policy-based access control.

In some cases, ABAC is also called claims-based access control. This tends to relate to Microsoft implementations, but the two models are interchangeable.

Access control policies set down the rules for accessing each resource. XACML or SAML code makes it easy to match up users and profiles.

A policy is a simple set of conditions. For example, the access policy might read:

• "If the subject is a senior lawyer, they should have full read, transfer, and edit access to case records and read access to legal databases."

In this policy, the subject is the "senior lawyer" employee tier. The policy specifies that "read", "transfer" and "edit" actions are allowed. And it mentions two resources – "case records" and "legal databases."

Admins could include a time element in access decisions. They might allow edit privileges "while cases are ongoing." Or they could allow access to "legal databases for cases in the United States."

Benefits of attribute-based access control

ABAC has become a standard way to manage access to critical resources. Since 2011, the Federal Chief Information Officers Council hasrecommended attribute-based controls for information sharing and storing critical data.

There are various reasons for the model's popularity. For example, the benefits of ABAC include:

• Flexibility - Companies can widen access by changing attribute settings, or tightly limit access as the situation demands. Financial companies can restrict transactions from certain locations or account types. Educational institutions can allow student access but keep every student profile completely separate.
• Easy to use – ABAC presents a simple interface for users. The use of common language in policies makes them accessible and easy to change. Computational language allows easy policy alteration and delivery to all relevant resources. IT teams can concentrate on technical issues and delegate many access management tasks to resource owners.
• Simplified onboarding – ABAC allows object or resource owners to create access policies for new hires and third parties. Users just need the right attributes to access critical resources. There is no need to make major rule changes to accommodate new hires.
• Privacy and security compliance – The core aim of ABAC is securing confidential data. Attribute-based controls add contextual factors to role-based privileges. Even with the right credentials, attackers will find it difficult to access data and transfer files.
• Stronger compliance – Better data security makes it easier to meet data protection regulations. Granular controls protect personally identifiable information – a key part of HIPAA compliance. Financial companies can tightly control access to customer accounts - a PCI-DSS compliance benefit.

Challenges of attribute-based access control

ABAC has many benefits. But one particular challenge faces all attribute-based access configurations: managing complexity.

ABAC can be complex. Administrators must define core attributes. They need to assign attributes to each resource. And they need to set up a policy engine at the network center. This engine defines the meaning of attributes and how they affect user access. All of this requires time and expertise.

Implementation can also be difficult. Administrators must match roles and attributes, ensuring that everyone has the correct permissions. This is hard to assess before the system goes live. There is often a lengthy period of adjustment as administrators fine-tune the access control system.

ABAC vs RBAC

ABAC builds upon role-based access control and differs from the older authorization model in several ways. This table of key differences compares the two access management methods:

ABAC

• ABAC builds on role-based authorization. It adds attribute-based access controls. Attributes like time of access, location, and role can be set for all applications.
• Administrators can make smart decisions for each resource. Granular controls change rapidly to handle new situations.
• Clearly defined policies explain privileges to relevant users. Policies can be as nuanced as admins require.
• Security managers can change attributes but do not need to rewrite policies.
• ABAC allows discretionary access control at a granular level.

RBAC

• Authorizes users based on predefined roles. Roles specify privileges that control access across all network resources.
• Limited scope for intelligent decision-making.
• Users receive little information. Roles are the sole criteria for granting access.
• When changes are needed, admins must re-configure roles, it's a time-consuming process.
• Access tends to be broad, applying across the whole network.

The basic difference between the two models is that ABAC systems grant access based on characteristics. RBAC systems grant access based on user roles.

Roles are static profiles based on job types and positions. For instance, a credit handler may have permission to view customer data within office hours from verified devices. These permissions apply to all credit handlers within the organization.

ABAC uses attributes instead of roles. These attributes include information about the user's identity and role. But they go further. Admins can set very precise controls on how users interact with resources. An access control rule could be based on time, location, duration of session, and allowed actions.

ABAC is more adaptable and secure. Security teams can apply smart access controls for sensitive data. They can change attribute-based controls without altering user profiles or roles. This streamlines data security and regulatory compliance.

Which model is the right fit for your business?

Attribute-based access is a simpler solution for large organizations. Administrators do not need to create and rebuild policies for every role. After the initial implementation phase, they can fine-tune attributes as and when required.

ABAC's security benefits also make it superior when defending sensitive data. RBAC can be vulnerable to credential theft. Attackers can compromise assets by stealing credentials. As long as they fit the role profile, the system will grant access.

ABAC adds more criteria to prevent unauthorized intrusion. Administrators can combine traditional role-based controls with contextual information that blocks outsiders.

ABAC also scales more efficiently as organizations grow. Maintaining roles is cumbersome at scale, and can lead to security gaps. It's far easier to extend attributes to new hires and third parties.

Nevertheless, role-based controls do have a role to play. Setting up ABAC can be expensive and complex for smaller companies. Organizations with smaller workforces can use roles to simplify their access systems. They can still achieve high security levels with encryption, firewalls, and other data security tools.

What should you consider before implementing ABAC?

When implementing the ABAC model, take care to plan the process:

• Make the business case for ABAC before purchasing any solutions. Be clear about the benefits of updating access controls. Estimate the cost of transitioning to new technology, and any changes needed to administer policies.
• Create a register of all applications and data sets that require attribute-based controls.
• Set out auditing processes to ensure attributes are functional and relevant.
• Create processes to manage object attributes across different departments. Be clear about access control rules, including how those rules are created and managed.
• Check that stakeholders understand ABAC rules before they become operational. Match policies with job roles to make sure controls allow seamless working.
• Source an interoperable ABAC solution that covers on-premises and cloud resources. Find a solution that fits your IAM systems and can absorb HR directories or existing controls.
• Decide how centralized or discretionary ABAC controls should be. Do you need complete central control, or can resource owners set attributes as they require?
• Establish processes to deal with broken access control. Build incident recovery into the ABAC setup to allow safe restoration of access for users.

In summary, ABAC allows granular contextual access controls. Administrators can set flexible policies for every resource, protecting confidential information and allowing employees the access they need.