ABAC, Anemones, and You

Virtru’s systems and products are built and architected around an Attribute-Based Access Control (ABAC) model. Data protection is our bread and butter, and so the kind of approach we choose to model how and when data can be accessed is of critical importance.

But what the heck is ABAC, and how does it work? 

There are many access control models, and you’ve probably used one within the last hour without realizing it! In fact, it usually helps to explain something by relating it to something else everyone is more familiar with. Let’s do that!

The Drawbacks of RBAC

One of the more common traditional models you’re likely familiar with is Role-Based Access Control (RBAC). In an RBAC model, actors in the system get assigned to groups — or “roles” — and those groups or roles have permissions to do specific things. 

If you’ve ever asked someone to “add you as an administrator” or uploaded a document to Sharepoint and shared it with your team’s group, you were operating within an RBAC model.

RBAC is quite common, but it has several specific, well-understood, and well-studied flaws and drawbacks — especially at scale:

RBAC suffers from “role explosion.”

RBAC systems of any size tend to devolve into a mess of lots of roles — too many to keep track of.

RBAC only supports static access decisions.

RBAC is fundamentally unable to make dynamic access decisions based on environmental and contextual inputs (e.g., “You have access for one hour if the moon is currently full at your location”). 

RBAC can’t support dynamic segregation-of-duty.

Anyone with the right role can do anything that role is allowed to do, no constraints. Modeling complex access requirements like, “The reactor can only be opened by two people from different organizations standing 15 feet apart” can’t readily be achieved with RBAC.

RBAC is simply unfit for managing individual rights and access.

RBAC only assigns permissions to groups and roles — not individuals. And roles are not the same things as identities. In a world where personal data is gold and Zero Trust is table stakes, it is simply no longer enough to say we protect data and access based on a person’s role. We need to be able to protect data based on someone’s identity. 

Those flaws and drawbacks boil down to a simple fact: RBAC is fundamentally incompatible with Zero Trust architecture, and is not naturally data centric. Which is why we don’t use it as the architectural foundation for our products: It simply fails to meet the two most fundamental requirements Virtru has!

Enter the (ABAC) Dragon

That’s RBAC, but what is Attribute-Based Access Control (ABAC)? 

ABAC supports dynamic access decisions.

ABAC supports dynamic segregation-of-duty. 

ABAC is perfectly fit for managing individual rights and access.

ABAC is a National Institute of Standards and Technology (NIST) standard.

The most important difference between RBAC and ABAC is that ABAC fundamentally has no roles or groups. At all. 

Instead, ABAC has attributes, which can be applied to different “things” (data, people) in different contexts.

ABAC can be used to emulate “roles” and “groups” and RBAC concepts — but this would negate the advantages of ABAC over RBAC.

So, let’s touch on the basics of ABAC.

What is ABAC? 

There are three fundamental “kinds of things” in an ABAC system you need to remember:

• Data
• Entities
• Attributes

If you need a mnemonic device for these three things, may I suggest:

Dank Erotic Anemone
Data - Entities - Attributes

Repeat that to yourself a few times while you look at this picture. I promise, it’ll help the concept stick.

Data

Data is the information that is being created and/or accessed in an ABAC system.

Let’s define some of these essential elements of the world of ABAC. First, there’s data. Data is any bit of information that any actor in the system creates or accesses. In Virtru terms, it is the user payload we encrypt and wrap inside a TDF. Virtru specializes in data protection, so this is, practically speaking, the primary thing we are interested in protecting and making decisions about. Sometimes other ABAC systems will call this a "resource" instead of "data."

When data is created, it has attributes assigned to it. The set of attributes assigned to data is called data attributes. The data attributes assigned to the data determine when, where, and by whom the data can be accessed.

Data attributes should exclusively describe characteristics of the data they’re attached to, and not the characteristics of the system that consumes them.

Entities

Entities are the things that are creating data or accessing data in an ABAC system. 

An entity is any “actor” in the ABAC system. Typically, actors are creating or accessing data. An entity may be a human user, or may be a machine acting on behalf of a human user, or may be a machine acting on behalf of itself–the general term for all of these is entity.

There are two basic types of entities:

• Person Entities (PEs): Human users. You are a person entity. I am a person entity.
• Non-Person Entities (NPEs): Everything else that creates and accesses data - machines, services, etc. 

Entities are assigned attributes, just like data. In general, ABAC systems should avoid distinguishing between non-person entities and person entities: They should be treated the same way in terms of architectural and design logic. The only real difference between any entity subtype is how they are entitled — that is, what entity attributes are assigned to them. Nothing else.

It is tempting to say that the set of entity attributes assigned to an entity “authorizes the entity,” but this is incorrect. Remember that attributes just describe the thing they are attached to, and have no meaning until interpreted at time of data access, so entity attributes do not, by themselves, authorize a user. To know that, you also need to know the “business rules” or logic that will be used to interpret the entity attributes.

Note that often in authentication flows, NPEs and PEs authenticate together. Think of a user (PE) using a mobile client (NPE) to authenticate with some backend. When that user creates data in a mobile app, it is the mobile app that handles the data, processes it, contacts servers on your behalf, and uploads it. Both the user and the mobile app are entities, and they are both distinct, and identified uniquely within the auth system, but are really being authenticated together as one thing — it is really the union of a PE and NPE that we are authenticating and authorizing.

This is an important and necessary distinction to make for Zero Trust data protection. A user may have access to data, but only from a specific workstation client, and not from their phone client, for instance.

Attributes

An attribute is a simple bit of text that describes some characteristic of the thing it is attached to. You might think of them informally as globally unique tags.

Attributes consist of a name, which is typically namespaced in some fashion to ensure global uniqueness, and a value. Attributes are typically encoded as simple key-value pairs.

For instance, an attribute named “username” with a value of “hortense” might be attached to a Person entity as a key-value pair:
Key:"https://virtru.com/username"
Value: "hortense"

As outlined, attributes get assigned to both data and entities. Attributes are subcategorized based on whether they are attached to an entity or data. In both cases, they are still just name and value pairs. They are just interpreted differently based on what they are attached to.

Attributes do not mean anything, or have any business logic meaning, until they are interpreted during an access decision. There are no “special” or “more important” or “hardcoded” attributes in an ABAC system. The username attribute above cannot and should not have any special system meaning. It is just a descriptive characteristic like “blue,” “hot,” or “fancy,” until something interprets it in the context of what entity or data it is attached to, and gives it a “meaning” in the business logic sense.

One More Piece: The Policy Decision Point

Remember: There are three fundamental “kinds of things” in an ABAC system:

• Data
• Entities
• Attributes

And you might be saying to yourself:

 “So I get that...

- Attributes assigned to Data are Data Attributes

- Attributes assigned to Entities are Entity Attributes

…but what actually ASSIGNS those attributes? And what actually compares entity attributes and data attributes?”

There is one more critical, basic type of component in an ABAC system that handles how those three fundamental things interact: A Policy Decision Point (PDP).

Every ABAC system has multiple PDPs that handle different aspects of policy, or what you might call business logic or business rules. PDPs are where the “business logic” or “business rules” live.

Policy Decision Points (PDPs) roll up Data, Entities and Attributes into Policy. 

A PDP is any service that compares or assigns attributes — in essence, making policy decisions.

• A Data Tagging PDP would assign Attributes to Data, based on business logic.
• An Entitlement PDP would assign Attributes to Entities, based on business logic - that is, it would Entitle an Entity.
• An Access PDP would: 
• Look at the Entity Attributes of the entity requesting Data
• Look at the Data Attributes of the Data
• Compare the two against each other to determine if the Entity can access the Data

Recap: 3 Key Elements of ABAC 

So to recap the key concepts of ABAC. Remember the Anemone! 

Dank Erotic Anemone
Data - Entities - Attributes

And the One Last Thing that ties those three fundamental components of an ABAC system all together: Policy Decision Points.

For a visual aid, here’s a basic diagram of the ABAC system we’re describing:

(Source: Imgur)

Build Your Zero Trust Strategy with ABAC

To summarize, ABAC gives you far more granular control than RBAC does. Because it’s truly data-centric, ABAC supports Zero Trust and is also flexible enough to meet different access needs as your business grows and changes in the future.