Policies or graphs: which approach works best?

Learn about the main models of authorization and how to choose the approach that best fits your access control landscape.

David Brossard   ·   Tuesday, October 1st, 2024   ·   Reading Time: 4 minutes

There are at least three different ways to tackle authorization: one being policy-driven authorization, another being access control lists, and the other being graph-based authorization.

But which approach works best when it comes to authorization?

First, we must understand the different types of authorization and how they relate. Below is a good overview of the different techniques mapped out by my friend Alex Babeanu.

Taxonomy of authorization

We’ll start by looking at the two big types: discretionary access control (DAC) and mandatory access control (MAC).

• DAC: Allows you to cherry pick which user/individual/client can get access to what particular resource and sometimes for what action. It is very similar to the Unix model of file permissions where you have to set a permission on the following file for a given user. Most importantly, there is no logic to DAC. A user decides they want to share an item with a user. There is no policy a priori behind the reason for sharing. This is why it’s called discretionary: a user decides what to share at their discretion.
• MAC: On the other hand of the spectrum lies MAC. MAC is all about defining authorization policies (in the broad sense) that determine what can happen, what access is allowed (or disallowed). MAC usually focuses on enterprise rules (e.g. do not share data on personal devices)

In summary, the difference between MAC and DAC is the source of the authorization requirement/logic. In MAC, it’s dictated by the enterprise, compliance body or government whereas in DAC it is up to the individual to decide whether or not to share that item with you. If you look at Google Drive, the bulk of authorization is DAC: the user chooses  to share a document with a colleague; Google Drive also has some basic MAC features e.g. disallowing external sharing for all regardless of the user’s DAC preference. This is an interesting point to keep in mind. It’s not MAC vs. DAC – both models can be combined (and in fact probably should for a comprehensive solution).

If we go further, you will notice that relationship-based access control (ReBAC), access control lists (ACL) and ZANZIBAR are all means to implement DAC. In his diagram, Alex doesn’t list policies under DAC. Technically, a policy could be used to express a DAC use case but it’s not a good use of policy. A simple database table or an ACL is enough to express DAC.

In the MAC world, they are further split into context-aware and context-agnostic. Context-aware authorization is where >attribute-based access control (ABAC) and policy-based access control (PBAC) live. This is also where you are going to find the policy languages like Abbreviated Language for Authorization (ALFA) and Rego. Note that a language’s ability to use context is not tied to the fact it’s a policy language per se. It’s tied to the framework’s ability to use contextual data. For instance, both Rego and ALFA can use time and location information. Other languages (e.g. SDDL) may not.

Main models of authorization

Beyond MAC and DAC (the end goal), there are different models to achieve authorization.

RBAC

Role-based access control (RBAC) was designed to try and simplify access control lists, user provisioning, and user access management. Rather than assign individuals a set of permissions, we group those permissions or entitlements into roles which we then assign users. It simplifies the burden of access management.

ABAC

ABAC is used to grant access based on any attribute of the user, action, resource, and context such as a user’s location, role, time of day, the device being used, the resource in question, and the desired action. It is more fine-grained and more risk-aware when compared to RBAC. It can cater to segregation of duty checks and lends itself to being expressed as policies.

What’s interesting with ABAC is that you can introduce any number of attributes. It could be user metadata, resource metadata, contextual data, relationships, actions, etc. We can use attributes to model  relationships and define policies based on those relationships.

PBAC

In more recent years some companies have been using the word PBAC, but it is generally the same as ABAC. The difference between the two is what particular item you want to focus on.  In ABAC, the stress is on the attributes and with PBAC the stress is on the policy. But the truth is, a policy would be nothing without attributes and attributes would be pointless without policies.

ReBAC

In ReBAC, what you are dealing with first and foremost is the data that you want to control access to. An example of this is if you have records, documents, users, etc. These are considered first class citizens. When you deal with the data, you have to define relationships between them. Those relationships are going to drive the authorization between the items. A typical example of a relationship would be ownership. Often, ReBAC systems will use graph databases as means to implement their authorization logic but that is not necessary. It’s worth highlighting that a fully-fledged policy-based ABAC system such as XACML, ALFA, or Open Policy Agent can easily be used to implement ReBAC.

What’s the difference?

ReBAC can only work with relationships as graph-based authorization and focuses solely on the user. Some of the benefits of using this approach is:

• Zero-code;
• It has native support for relationships, dependencies, and hierarchies; and
• It has rich schemas that make data reasoning easier.

It is also the only graph-based approach to authorization out of the four main models of authorization.

However, ABAC and PBAC can handle relationships in addition to other attributes. This means that they can handle a wider variety of use cases as they take into account more factors. Some of the benefits of using a policy-based approach is:

• It enables policy-as-code which is easier for app developers and owners;
• There is more flexibility as you can use any attribute;
• It mirrors policies in English more closely;
• Some policy languages (such as ALFA) support conflict resolution and combination natively;
• There is no need to preload data; and
• Policies can express negative cases.

Take the next steps

Watch the full recording of my LinkedIn Live where I detailed the different authorization approaches and how to determine what’s right for you. Plus, you get to see a breakdown of how to write policies and some of the different policy languages.

Ready to gain more knowledge on policy-driven authorization? Here are some additional resources that look at this topic:

• Why traditional IAM solutions are no longer enough
• Three phases of growth when implementing policy-driven authorization
• State of Authorization: Playbook Edition (newly updated!)

Make sure to join us on LinkedIn Live or YouTube for future events as I tackle common questions that we see arise in the industry.