ABAC Patterns: What is Attribute Based Access Control

TL;DR

• Attribute-Based Access Control (ABAC) is a pattern for determining whether a user is authorized to perform a certain action based on attributes, such as user identity, role, department, location, time of access, and more.
• ABAC is a broad pattern that is a superset of other authorization patterns, like role-based access control (RBAC) and relationship-based access control (ReBAC). Both RBAC roles and ReBAC relationships can be thought of as attributes of the actor and the subject.
• ABAC is ideal when you need more fine-grained controls and want to define access based on context. For example,  a support engineer can run diagnostics on a customer system only if their role and certification match the customer’s subscription tier, the data sensitivity is within their clearance, the request comes from a trusted network during support hours, and their manager has approved access to the high-sensitivity system.
• In this article, you will learn what ABAC is, the differences between ABAC and other access control models, and how you can implement ABAC with Oso Cloud.

What is ABAC, and how does it differ from RBAC?

ABAC is a pattern for determining whether a user is authorized to perform a certain action based on attributes associated with the actor or the subject of the action.

ABAC is a broad pattern that is a superset of many other authorization patterns, like RBAC and ReBAC. Both RBAC roles and ReBAC relationships can be thought of as attributes of the actor and the subject.

Most applications begin with an RBAC model, where users are assigned permissions based on roles. The role describes a person’s job, and the job determines what actions they can take.

In an HR system, RBAC might look like this:

RBAC is simple and works well when responsibilities map cleanly to job titles.

In contrast, ABAC determines what a user can do based on attributes, which could be facts about the user, the resource, or the situation. Continuing on our HR example, attributes could be things like a user’s department, region, employment status, or whether they are currently on leave. In ABAC, you can create more granular controls, such as:

• “Managers can approve PTO only for employees in their department.”
•  “Employees can submit PTO only if they are full-time.”
•  “HR Admins can view profiles only in their region.”

Key Differences between RBAC and ABAC:

How do I implement ABAC?

Oso Cloud has several neat features that can help you implement ABAC. If you haven't already, create a free Oso Cloud account and log in. For the purposes of this tutorial, we will have one type of actor, a User, and one type of resource, a Repository. Below is how we can represent these entities in Polar, Oso's declarative authorization language.

Let's add an is_public attribute to repositories, and a rule that says users can read repositories that are public.

Navigate to Oso Cloud's "Explain" tab, which lets you simulate authorization queries. By default, the user Bob can't read the repository website because the repository website does not have is_public set.

In Oso Cloud, facts are how you represent authorization data, including ABAC attributes. You can represent whether a repository is public as a fact. Navigate to the "Data" tab in the Oso Cloud UI, and add a new fact that indicates that the repository website has is_public set to true.

Now, navigate back to Oso Cloud's "Explain" tab. Now that the repository website has is_public set to true, Oso Cloud can infer that the user Bob can read the repository website.

The “users can read public repositories” rule is an example of the “Attribute checks” pattern from Oso’s 10 Types of Authorization blog post. Another ABAC pattern from that blog post is called “Attribute add-ons”, which mixes ABAC patterns with RBAC and ReBAC. For example, the following rule tells Oso that “users can write public repositories if they have the member role.”

What is an example of ABAC in practice?

One of the most common places developers see ABAC in practice is AWS ABAC, which allows developers to write authorization rules for AWS resources using AWS' custom syntax. AWS ABAC is an example of the “Custom policies” pattern from Oso’s 10 Types of Authorization blog post because it allows developers to define arbitrary policies.

For example, the following JSON defines an AWS policy that allows actors (AWS calls actors principals) with tag "project" to invoke Lambda functions with tag "project". In this case, a tag is an attribute on both actors and resources.

The example shows why ABAC is such a blanket definition. Rename “tag” to “role” and the same logic still works: actors with role “admin” can invoke any Lambda function with tag “project”. So this AWS ABAC example can be represented as a mix of RBAC and ABAC.

See our guides for additional ABAC patterns, like Public and Private repositories and Entitlements.

Moving on

RBAC and ABAC are two of the most popular authorization patterns. ABAC is more powerful and flexible, but RBAC is similar and easier to work with. With Oso Cloud, you don't have to chose between RBAC and ABAC: Oso Cloud makes it easy to implement both when you need to. So sign up for Oso Cloud.