GoKawiilby Andrea Chiarelli
In Is Policy-Based Access Control (PBAC) an Authorization Model?, I argued that PBAC gets compared to Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) as if it belonged in the same category, when it actually answers a different question.
RBAC and ABAC describe what data a decision is based on: a role, an attribute. PBAC describes how that decision gets made: through a centralized policy engine instead of logic wired into the application. One is about the shape of the rule. The other is about where the rule lives and who evaluates it.
In my opinion, treating them as competing options is like comparing a recipe to a kitchen.
That distinction attempted to solve one specific confusion, but it left a bigger one untouched: PBAC isn’t the only term that gets misfiled this way.
Mandatory Access Control (MAC) and Discretionary Access Control (DAC) get compared to RBAC and ABAC too, even though they describe who administers the rules, not what the rules look like.
Access Control List (ACL) and Relationship-Based Access Control (ReBAC) show up in the same breath as “authorization models,” but one is arguably a special case of the other, depending on which paper you read.
The terminology around authorization has accumulated for decades across access control research, identity vendors, and standards bodies, and a lot of it answers different questions while using the language of a single one: “what model is this?“
This piece generalizes the model-versus-architecture distinction into a full taxonomy. Instead of asking “which authorization model is this system using?“, I want to ask five narrower questions about any authorization system, answer each one independently, and only then see where familiar labels like RBAC, ABAC, MAC, and PBAC actually land. If the terms stop competing once they’re placed on the right axis, that’s a sign the axes are doing real work.
The Core Problem of Authorization
... continue reading