TL;DR: In this blog post we outline 10 authorization models types that are members of the RBAC (Role-Based Access Control), ReBAC (Relationship-Based Access Control), and ABAC (Attribute-Based Access Control). These patterns of authorization will help you articulate the rich relationships you want to build in your applications, that the higher level terms RBAC, ReBAC and ABAC sometimes fail to express.
The 10 Types of Authorization
I once met with an engineer who needed to build something akin to Google Docs. With Google Docs, a user has a role—Editor, Commenter, or Viewer—and each role has a different type of access to a document.
If Rose has the Editor role for document A, she has full access to the document and can change what she wants; if Jackson has the Viewer role for document A, he can see the document, but he cannot make any changes. And just because Rose is an Editor on document A, that doesn’t mean she is an Editor on document B. Roles are assigned to users on a per-document basis.
The engineer said he was looking for the right role-based access control (RBAC) solution. These models center around the roles users have and define access from there, so seemed intuitively right. But the way RBAC is normally defined didn’t fit with his use case.
That’s because the RBAC definitions online are too high level and imprecise. RBAC isn’t an authorization model–it’s a collection of authorization models.
When I told him that what he needed was resource-specific roles, a subset of RBAC, a lightbulb went off in his head.
Being able to recognize a problem and name it is a superpower in software engineering. It helps you pattern-match the problem at hand with existing solutions.
So to help you with that, we want to name the existing solutions. At Oso, we’re constantly reevaluating this list, but currently we use ten definitions within the three core models of authorization–RBAC, ReBAC, and ABAC–to better delimit the entire scope of authorization:
Before we go through each of these models, there’s one thing to note–all of them are related.
That is, that the higher order models are like Russian dolls. They are all not just subsets of access control, but they are 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.
This is because of the way attributes, relationships, and roles intersect. A relationship is a type of attribute (e.g., group membership is a relationship between a user and a group, and an attribute of the user), and a role is a type of relationship (e.g. an editor on a document is a role, but there is also a relationship between that role and the document).
Also worth noting: teams often figure they should pick one model or another. That’s a false dichotomy. You rarely need just one of these ten models. Perhaps for the very first iteration of your app you might only have global roles, but before long you’ll start to use a blend of many authorization models together.
Let’s go through each one in detail so you know how they can fit into your application.
RBAC: Definitions under the role-based access control (RBAC) model
The original idea behind RBAC was to make it easier to manage user permissions by grouping them together into roles. This role grouping principle is what ties together all the different kinds of RBAC – where they differ is the granularity at which the roles are applied.
1. Global roles
What this is: The simplest form of RBAC. With global roles, the user’s role applies across the entire application.
Example: A few internal “superadmins” in an app have greater access than the general “member” role, so they can access all organizations or accounts (usually for technical support).
Learn more about global roles here.
2. Organization-level roles
What this is: Organization-level roles are like global roles but segmented by organization or tenant.
Example: An “admin” or “owner” in an organization in a B2B application has greater access than a “member” of that organization (e.g., they can add users to the organization).
Learn more about organization-level (also known as Multitenant) roles.
3. Resource-specific roles
What this is: Resource-specific roles apply at a much more granular level in the application down to the (you guessed it) resource level. Resources are the objects–organizations, repositories, documents, folders, files, issues–that your roles and permissions can protect. If an application has projects or filesystems, it’s likely going to have resource-specific roles.
Resource-specific roles tend to have meaningfully different requirements relative to global and org roles – and therefore, more different implementations.
Example: Google Docs, where you can have a viewer, commenter, or editor role for a document.
Learn more about resource-specific roles here.
4. Custom roles
What this is: When enterprise customers want to create their own roles from a set of predefined permissions, these are called custom roles. Instead of roles only being statically defined in a policy, the customer can create their own roles as needed.
Example: Adding custom roles to your organization in Microsoft Azure.
Learn more about custom roles here.
ReBAC: Definitions under the relationship-based access control (ReBAC) model
There are three different kinds of relationships within ReBAC. However, they all end up with roughly the same implementation – a relationship between a thing and a thing – as they’re all actually just other ways of representing the same access models you’ve probably seen elsewhere.
5. Actor-Actor Relationships
What this is: Relationships that relate to two actors (e.g., two users, groups). For instance, an organization’s incident response group can be made up of subgroups that are made up of subgroups. Each group at each level is an actor and has a relationship upwards, downwards, or across with other actors. It’s common that permissions flow “up” the chart in these scenarios (e.g., the Internal Response Group has all permissions that the HR Group and Operations Group have)
Example: Org charts, social network graphs, and groups.
Learn more about actor-actor relationships here.
6. Resource-Resource Relationships
What this is: Relationships that relate to two resources. For instance, in GitHub, every organization (a resource) has repositories (a resource) which contain files (a resource). These are usually hierarchical, like with GitHub. Here, it’s common that permissions flow down the hierarchy, e.g., with GitHub, Organizations are the parents of Repositories, which can be parents of Folders or Files. The Folders can then be parents of other Folders or Files, and so on down the hierarchy.
Example: File/folder structures, issues that belong to repositories, projects that belong to organizations, and so on.
Learn more about resource-resource relationships here.
7. Actor-Resource Relationships
What this is: Combine the above two concepts, and voila, you have a relationship between an actor and a resource. The relationship could be explicit – ”a user has the read relation on this folder” – or implicit – ”a user has the read relation on this folder, and readers of folders can read the files within them.”
Note that in both of these cases, we’re just representing resource-specific roles, which we already defined above.
Example: An expense submitter can see the expense report they added. This isn’t a role, as it can’t be assigned–it is a relationship between the actor (submitter) and the resource (report).
ABAC: Definitions under the attribute-based access control (ABAC) model
There are a range of flavors of ABAC, from the simplest attribute checks to full-on dynamic systems like AWS IAM.
8. Attribute checks
What this is: Most of the time, when people talk about ABAC, they mean the ability to do simple attribute checks/comparisons on resources or users.
Example: In GitCloud, the owner of a repository can mark it "public." Public repositories are visible to anyone, but an owner can also set a repository to private. The same is true for documents in Google Docs or Dropbox.
Learn more about public and private resources.
9. Attribute add-ons
What this is: You can add attribute checks to other kinds of permission checks, too. It’s like an extra conditional tacked onto the original check.
Example: “Users can create private repositories if they are a member of the org, AND if the org allows private repository creation.”
These are simple toggles for turning on and off permissions.
10. Custom Policies
What this is: The final form of ABAC is user-configurable policies. In this case, not only is the data dynamic but so is the logic. And at this point, there effectively is no “model” – the model is whatever the user writes in their logic.
Example: AWS IAM
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example_bucket",
"Condition": {"NumericLessThanEquals": {"s3:max-keys": "10"}}
}
}
Abstract models vs. granular definitions
If we go back to the engineer we met at the beginning, he had a problem – a problem that the authorization domain failed him on.
Our engineer reached for “RBAC,” but that didn’t seem to fit his use case because he thought the only form of RBAC was organization-level roles. That is, it wasn’t that there was no solution; in fact, there was a perfectly good one. But the terms misled him (and he later told me he wasted three days because of this). Then once he learned about another kind of RBAC – resource-specific roles – he was unblocked. In this way, the terms we use to describe the domain matter a lot to our ability to solve the problems at hand.
And this engineer is not alone. After speaking with 1,000+ engineering teams, I’ve found that the terms RBAC, ReBAC, and ABAC don’t do nearly enough to provide the superpower we talked about at the beginning. These terms are 1) so broad, and 2) overlapping, that in practice they don’t help engineers pattern-match and solve problems.
So, here we’ve outlined ten definitions to help engineers pattern match and advance the state of thinking on the authorization domain. There are likely more patterns, but for now this is a start. If you have your own ideas or questions on different authorization models, join the Oso Community Slack, where you’ll find the Oso engineering team and almost 2,000 other developers working on authorization.
