Policies, Graphs or Relationships - A Modern Approach to Fine-Grained Authorization

Authorization is becoming more important than ever as the growth in data, services, apps, and users shows no sign of slowing down. Making sure the right individuals have access to the right data under the right circumstances is paramount. In this presentation, I will discuss the different approaches to dynamic, runtime authorization.

1. Policies, Graphs, or Relationships W hat approach works best? David Brossard, May 2024

2. A Taxonomy of Authorization Models

3. RBAC, ABAC, PBAC, ReBAC RBAC - 1992 - NIST (Ferraiolo et al.) - Role Based Access Control RBAC ABAC - 2013 - NIST (Ferraiolo et al.) - Attribute Based Access Control ABAC PBAC - more of a marketing term. Generally the same as as ABAC ReBAC - 2007 - IEEE Paper by Carrie Gates - (PDF) Access Control Requirements for Web 2.0 Security and Privacy

4. Two camps Policy-First OASIS XACML Open Policy Agent Rego ALFA AWS Cedar OSO Polar Cerbos Relationship-first Zanzibar ( just a model) NGAC OpenFGA SpiceDB (AuthZed) 3Edges Topaz (hybrid model)

5. ABAC & PBAC… Basics Everything is attributes Policies combine attributes together Attributes can represent contextual data Time | Location | Risk | Device Policies are decoupled from data Retrieve your data from wherever it lives Example P: A person can fish non-endangered species during daytime if they have a valid permit and they have not exceeded their daily quota. Q: Can Joe, the teenager on vacation, fish trout in Glacier National Park at 2pm? A: 🎣(Permit) Location Time Identity Age Action Resource Conservation

6. Examples of ABAC Policies default allow := false allow if user_is_owner allow if { user_is_employee action_is_read } allow if { user_is_employee user_is_senior action_is_update } allow if { user_is_customer action_is_read not pet_is_adopted } policyset records{ target clause objectType== "record" apply firstApplicable policy viewRecords{ target clause actionId== "view" apply firstApplicable rule managers{ target clause user.role == "manager" permit } rule owner{ permit condition record.owner==user.employeeId } }} permit ( principal == PhotoApp::User::"alice", action == PhotoApp::Action::"viewPhoto", resource == PhotoApp::Photo::"vacationPhoto.jpg" ); permit ( principal == PhotoApp::User::"stacey", action == PhotoApp::Action::"viewPhoto", resource ) when { resource in PhotoApp::Account::"stacey" }; Rego (OPA) ALFA AWS Cedar

7. ALFA Policies can be visualized… 🥁 as graphs (sort of) Attorney View Court Reporter Transcript DO ▼ - - - - Permit if the attorney is assigned to the case. Permit if the attorney is in good standing. Permit if the attorney is licensed. Permit if the attorney checks are all good. - - - - - - - - The attorney must be assigned to the case. The attorney must be in good standing. The attorney must be licensed to practice in court. The attorney must be cleared. ✔ ✔ ✔ ✔ DuP ▼ DuP ▼ DuP ▼ DuP ▼

8. Graph-based AuthZ: ReBAC-first ReBAC defines an authorization paradigm where a subject's permission to access a resource is defined by the presence of relationships between those subjects and resources. Data becomes front and center. Data is modelled onto a graph → Graph-based authorization In general, authorization is performed by traversing the directed graph of relationships. The nodes and edges of this graph are very similar to triples in RDF.

9. Examples of Graph-based systems Aserto (Topaz) Authzed (SpiceDB) OpenFGA (Okta) 3Edges NGAC (NIST implementation) 3Edges Example

10. Stateful vs. Stateless In order for graph-based systems to fully work, you need to suck in all the data you want to reason about. This creates a stateful system Generally, ABAC (Policy)-based systems rely on a P*P architecture with the notion of a PIP that fetches data on-demand. This creates a stateless system. These are easier to maintain but may introduce latency at runtime

11. Pros & Cons Pros of the Policy Approach ABAC/PBAC enables policy-as-code Easier for app owners to developers Policies mirror English more closely Some languages (ALFA) support conflict resolution and combination natively More flexible: use any attributes No need to preload data Policies can express negative cases Pros of the Graph Approach Zero-code Native support for relationships, dependencies, and hierarchies Richer schema makes data reasoning easier

12. Summary of Pros & Cons ABAC ReBAC Use case ABAC allows the creation of fine-grained policies based on user and resource attributes, significantly extending upon basic RBAC. ReBAC is designed to represent hierarchies and nested relationships, making it the most suitable choice for managing permissions for complex hierarchical relationships. Representation of Relationships Can be cumbersome and verbose when managing access to hierarchical structures where the nesting of resources under other resources is present. Excellent for representing hierarchies and nested relationships Reverse Indices (who has access to y, instead of does x have access to y) Implementing reverse indices is very difficult Naturally supports reverse indices (Thanks to ReBAC’s graph-like nature). Performance Often provides better query performance but can be heavier on data mapping and loading. Data mapping is usually easier, but the recursive nature of relationships can produce inefficient queries. Homebrew-Implementation Complexity Medium complexity compared to other models* Highly complex Granularity Extremely high level of granularity Higher granularity than RBAC, not as granular as ABAC** Policy definition Permissions can be defined en masse instead of individually for every single resource by using teams and groups. They can also be added/removed from an application without requiring complex data migrations (e.g., adding/removing permissions for each individual user record)*** Auditing difficulty More complex than RBAC, yet still easily auditable if set up correctly. The complexity and recursive nature of ReBAC policies can make auditing challenging. (courtesy of Permit.io)

13. OpenID AuthZEN: Providing Interoperability between approaches Different authorization implementations (graph, ABAC…) do not all use the same interface Most are 90% the same Within the OpenID AuthZEN Working Group, we decided to standardize across all solutions Step 1 Simple Permit/Deny request/response protocol Step 2 Multiple decision approach: bundle multiple requests into a single one and receive multiple decisions back Other WIP Design patterns (integration with OAuth-style approaches) Support obligations in responses ‘Search’ API Do you want to take part? OpenID AuthZEN Join us at the Identiverse AuthZEN Interop on 5/28 in Vegas. Try the Axiomatics AuthZEN PDP at https://pdp.alfa.guide and using the Postman Collection

14. Pick the best of both worlds You can have vanilla and chocolate ice cream together (and also hold a cone of pistachio ice cream) Platforms like OpenFGA, Topaz, and Axiomatics provide a combined approach: Topaz uses a mix of OPA and ReBAC OpenFGA uses Google CEL Axiomatics can model relationships through attributes.

15. Upcoming Events Identiverse 2024 ▶ The Authorization Conversation ▶ Navigating the Intersection: IAM and OWASP in the Cybersecurity Landscape ▶ Don’t Ask for Forgiveness, Ask for Permission! European Identity Conference 2024 ▶ Unpacking Authorization Approaches: Policy as Code Versus Traditional Business Needs ▶ How AI Can Help IAM Deliver Better and Stronger Authorization ▶ Panel: OpenID AuthZEN: Standards for Modern Authorization ▶ Panel: Why Authorization Standardization is Imperative ▶ Panel: Policy Engines in Practice Identiverse May 28 th - 31 st Las Vegas, USA European Identity Conference June 4 th - 7 th Berlin, Germany

16. Additional Reading Authorization Concepts (Auth0) Intro to Attribute Based Access Control (ABAC) ALFA - the Abbreviated Language for Authorization The Authorization Substack Newsletter IIW 2023 - Introduction to ALFA 📺 The Holy Grail of IAM: Getting to Grips with Authorization