Attribute-based Access Control (ABAC for short) 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 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. In this blog post, you will learn what ABAC is, and how you can implement ABAC with Oso Cloud.
How does ABAC use attributes to express access control rules?
Authorization can be represented as a question: does the given actor have permission to perform a certain action on a given resource. An attribute is any property that is associated with the actor, the action, or the resource. You can think of an attribute as a column in a SQL database.
For example, consider GitHub repositories. Repositories have an is_public attribute: if a repository is public, any actor can read the repository. Users have an is_copilot_subscriber attribute: if a user has a paid subscription, they can access GitHub copilot. These are both examples of attribute based access control policies.
What are the differences between ABAC vs RBAC?
ABAC is a broad, almost vague pattern that encompasses just about any authorization pattern. RBAC can be represented as a subset of ABAC where the only attribute you consider is the actor’s role. When you’re building a new app, you’re more likely to use RBAC than ABAC when you first introduce authorization. Because roles are easier to compose and easier to reason about, particularly when they line up with real world job titles and roles.
At Oso we believe that the standardized nomenclature the industry has ascribed to authorization is limiting. Firstly, ABAC, RBAC and ReBAC are all related. The higher order models are like Russian dolls, subsets of different types of access control patterns, and also subsets of each other. ABAC encompasses all access control models effectively (“Anything can be expressed as an attribute!”); ReBAC is a subset of ABAC; and RBAC is a subset of ReBAC.
Additionally, when you’re implementing access control, you’re often implementing a pattern which is a subset of RBAC, ABAC or ReBAC. At Oso, we’ve documented ten of the most common types of access control that we’ve seen with our customers.
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.”
Learn how to implement ABAC in Node.js with Oso Cloud
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 next time when you're looking to implement RBAC or ABAC, try plugging your requirements into the Oso Modeler. Then, when you’re ready to integrate your model into your app, sign up for Oso Cloud.
