If you’ve spent any time designing secure systems, you’ve explored the wonderful world of authorization acronyms: RBAC, ABAC, ReBAC, and… PBAC. For a long time, I tried to line them up neatly in my head.
For Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and Relationship-Based Access Control (ReBAC), I can find a common thread. I can consider them part of the same family. They represent distinct, abstract ways of thinking about permissions.
But Policy-Based Access Control (PBAC) always felt like the odd one out. Actually, it is not the only odd one out: Mandatory Access Control (MAC) and Discretionary Access Control (DAC), usually included in the family of authorization models, seem like intruders to me as well, but that is another story.
Including PBAC in the same list as RBAC, ABAC, and ReBAC is misleading, in my opinion. Especially if you want to understand what the best authorization model is for your scenario. Comparing PBAC with RBAC, ABAC, and ReBAC sounds like comparing apples and oranges.
This confusion led me down a rabbit hole, and I’ve come to a conclusion: Policy-Based Access Control is not an authorization model. At least, not in the same sense as RBAC, ABAC, or ReBAC. It’s something different, and the distinction is crucial for a clear comparison between these things.
The Common Thread
Before we tackle the outlier, let’s look at what RBAC, ABAC, and ReBAC have in common. While they function differently, they are all built on the same fundamental premise: they make authorization decisions by evaluating a specific type of data. This data is the core input that defines the model itself.
RBAC relies on one primary piece of data: the user’s assigned role(s). The entire decision-making process boils down to the question: “Does the role assigned to this user grant the permission to perform this action?”
ABAC utilizes a much richer set of data: attributes. These aren’t limited to the user’s role; they can describe the user (department: ‘Finance’), the resource (sensitivity: ‘Confidential’), the environment (time_of_day: ’09:15′), and the action itself (type: ‘read’). The decision is made by evaluating these attributes against a set of rules and answering the question: “Do these attributes grant the permission to perform this action?”
ReBAC, as the first name in the acronym implies, relies on data describing the relationships between the user and the resource. It answers questions like, “Is this user the owner of this document?” or “Is this user a member of the team that has editing access to this project?” or, more in general, “Is there any relationship between the user and the resource that grants permission to perform this action?”
The common thread is evident: each model is fundamentally defined by the kind of information it considers. They are abstract blueprints for permission logic, distinguished by their primary data input: roles, attributes, or relationships.
What Is Policy-Based Access Control?
Now let’s turn to PBAC. If I summarize the definitions of PBAC I have encountered, I can condense them into the following one:
PBAC is an authorization model that grants or denies permissions to resources based on a set of rules, or policies, evaluated in real-time.
If we attempt to analyze it through the same lens used for RBAC, ABAC, and ReBAC, we immediately run into a problem. What specific type of data does PBAC rely on? As far as I understand, the answer is: none in particular.
PBAC does not prescribe what data you should use to make an authorization decision. Instead, it describes an architectural pattern for how to structure and execute your authorization logic. The core principle of PBAC is the externalization of authorization logic from the application’s business code into a centralized “policy engine.”
The crucial point is that the rules within the policy engine can be based on anything! You could write a policy that enforces RBAC, ABAC, ReBAC, or any hybrid model you can imagine.
PBAC is the machinery, not the logic upon which to make authorization decisions. It is fundamentally unconcerned with the type of data being evaluated, which makes it structurally different from the other models.
So, What Is an Authorization Model?
This contrast forces me to formulate my own definition of an authorization model. Based on the evidence, I propose a simple definition slightly inspired by the one given here:
An authorization model is an abstract model that defines the core inputs required to make access control decisions.
This definition is about the what, not the how. It defines an authorization model as an abstraction, regardless of its architecture and implementation. It answers the fundamental question: “What pieces of information do I need to look at to decide if a subject can perform an action on a resource?“
I know this may sound totally arbitrary, but this is how authorization models look to me. Also, this is not a prescriptive article, but rather a perspective one! 🙂
Under this definition, RBAC, ABAC, and ReBAC fit perfectly. They are true models because they are defined by their core inputs—roles, attributes, and relationships, respectively.
PBAC, however, does not fit. It’s an architectural pattern that provides a possible way to implement these models in a clean, decoupled manner.
Conclusion
So, is PBAC an authorization model? No. It’s a powerful and highly recommended architectural pattern for building flexible, scalable, and maintainable authorization systems.
By treating it as such, we can think more clearly. Our design process becomes two-fold:
- Choose your model(s): “For this part of your system, RBAC is sufficient. For this other, more dynamic part, you’ll need ABAC.”
- Choose your architecture: “Will you embed this logic directly in the code, or will you adopt a PBAC architecture with a centralized policy engine to manage it all?”
This separation of concerns is powerful. It allows us to pick the appropriate logical model for the job and the best architecture for our scalability and maintenance needs. So next time you’re in a design meeting, let’s stop comparing apples and architectural patterns and use these terms with the precision they deserve. 🙂
Additional Resources
- A Taxonomy of Modern Authorization Models
- The State of the Union of Authorization
- An Overview of Commonly Used Access Control Paradigms
Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.
About the author
Andrea Chiarelli is a Principal Developer Advocate at Auth0 (Okta). He has extensive experience in software development, holding various technical roles. In recent years, he has focused on Identity, developing a passion for the core concepts, which he aims to disseminate to developer communities.
