I should have read NIST SP800-63-4 2pd, but for some reason I ran away from it."ABAC vs. ReBAC: A Showdown of Authorization Policies"I just finished watching a YouTube video titled "How to Make a Video About Yourself." I've written a summary of the video in Notta below.
YouTube video summary
In this video, Gabriel, Alex, and David discuss Attribute-Based Access Control (ABAC) and Relationship-Based Access Control (ReBAC), aka Policy as Graph. They explore the key differences between these two approaches to fine-grained authorization, the benefits of each, and potential use cases. The discussion also touches on providing a good developer experience, integrating authorization into the software development lifecycle, and the potential adoption of these approaches by SaaS and COTS vendors based on customer demand. Additionally, they discuss the future of policy languages like Alpha and possible standardization efforts.
Main points
Introduction and Background
The video starts with Gabriel introducing Alex and David as experts on ABAC and ReBAC. They discuss the concept of fine-grained authorization and how it differs from traditional role-based access control (RBAC) by considering additional dimensions such as resource attributes, context, and relationships. In an interesting move, they start by touting the benefits of the opposite approach to their respective "preferred" approaches.
00:07:06 Benefits of ReBAC (Policy as Graph)
First, David, an ABAC advocate, defends ReBAC and highlights the advantages of using a graph-based approach for authorization, including the ability to use existing tools and frameworks, the ability to perform open-ended queries (search and reverse query evaluation), and a visual representation of the policy (aiding understanding). Alex adds that graphs are well suited for analysis and can leverage existing graph algorithms.
00:11:50 The Benefits of ABAC (Policy as Code)
Next, ReBAC advocate Alex discusses the benefits of ABAC, also known as policy as code. He suggests that it may have a low learning curve for developers comfortable with coding, and that it is based on the mature XACML standard. David adds that ABAC policies can closely reflect requirements in plain English, making them easier to understand and maintain.
00:17:20 Managing Complexity and Adoption
The discussion turns to managing the complexity of fine-grained authorization and potential adoption by SaaS and COTS vendors. Gabriel suggests partitioning users and resources into coarse-grained roles and groups, and then applying fine-grained policies on top of that. David mentions the OpenID Foundation's AuthZen working group, which he says could standardize authorization APIs and drive adoption by vendors.
00:51:00 Developer Experience and Integration
Panelists emphasize the importance of providing a good developer experience and seamless integration into the software development lifecycle. They discuss the potential for new policy languages and tools to improve the experience, as well as the trend toward no-code solutions. David mentions the ongoing efforts to evolve and potentially standardize the Alpha policy language.
00:55:46 Distinguishing between authorization and application logic
In response to a question from the audience, David provides guidance on distinguishing between authorization policy and application logic: He suggests that authorization policy should be side-effect free and focused on reporting requirements, whereas application logic can deal with business rules without strict reporting needs.
Impression
The AuthZEN WG activity in the OpenID Foundation is one of the activities that is starting to attract attention. The three people who appear in this conversation are people involved in this. Even PDPs (Policy Decision Points) that take such a different approach should be able to notify PEPs (Policy Enforcement Points) of their decisions, and AuthZEN is developing such standards. If you are interested, please join us.