Deep Dive Into Google Zanzibar and its Concepts for Authorization Scenarios

In 2019, Google published the Zanzibar paper, which explains how the system that powers authorization for all their products (Drive, Youtube, Cloud, and more) works. Since then, Zanziba-inspired systems have risen in popularity due to their capabilities. Companies like Carta and Airbnb have created their implementations, and open source and SaaS implementations of Zanzibar-inspired systems have surfaced.

Zanzibar has even become an authorization and access control trending topic, but getting started with Zanzibar-inspired implementations can be a daunting task. Understanding the paper and its concepts from scratch can be challenging, and the approach Zanzibar proposes for making authorization decisions is fairly different from both RBAC and ABAC. Additionally, many of the implementation decisions behind Zanzibar are fairly specific to Google and its internal use. All of this poses a challenge for teams looking to implement and get adoption of Zanzibar-inspired systems at companies.

Come to this session to learn what the "Zanzibar approach" is, how it works, when you should use something like it, and how you can get started, either from scratch or starting from an existing PBAC solution.

Transcript

1. Session Deep Dive Into Google Zanzibar and its Concepts for Authorization Scenarios #identiverse
2. Principal Architect at Auth0/Okta Damian Schenkelman #identiverse
3. Agenda #identiverse • Authorization Background • Intro to Zanzibar • How it works • How to get started • When to use it
4. Authorization #identiverse
5. For scale: • Access Review • Change Management • Auditable • Reliable • Fast Developer Requirements #identiverse
6. Typical Approaches #identiverse
7. Too coarse, imagine Instagram with role "Picture Viewer" Role Explosion Token bloat RBAC #identiverse
8. ABAC #identiverse 01 02 03 04 05 06 07 08 09 enum Decision { Allow, Deny, … } Decision {policyName}(sub, action, obj, ctx) { … }
9. #identiverse ABAC Architecture
10. How ABAC meets Dev Requirements #identiverse For scale Access Review Change Management Auditable Reliable Fast
11. Google Zanzibar #identiverse
12. Used for #identiverse
13. Middle ground #identiverse Google Zanzibar (Authorization "as a Service” ) DBaaS (handles data) Policies (Authorization needs)
14. Relationship based access control (ReBAC) #identiverse
15. "Does user S have relationship A to object O?" "Can subject S perform action A on object O?" Rephrase the question #identiverse
16. Rephrase the question #identiverse Request: check("anne", "viewer", "doc:roadmap") --- Response: true "Does user S have relationship A to object O?" "Can subject S perform action A on object O?"
17. How do Zanzibar-like systems work? #identiverse
18. 01 02 03 04 05 06 07 08 09 10 11 12 13 14 Namespaces #identiverse name: "doc" relation { name: "owner" } relation { name: "editor" userset_rewrite { union { child { _this {} } child { computed_userset { relation: "owner" } } }}} relation { name: "viewer" ... }
19. 01 02 03 04 05 06 07 08 09 10 11 12 13 14 Namespaces #identiverse name: "doc" relation { name: "owner" } relation { name: "editor" userset_rewrite { union { child { _this {} } child { computed_userset { relation: "owner" } } }}} relation { name: "viewer" ... }
20. 01 02 03 04 05 06 07 08 09 10 11 12 13 14 type doc relations define owner as self define editor as self or owner define viewer as self or editor A "translation" #identiverse 01 02 03 04 05 06 07 08 09 10 11 12 13 14 name: "doc" relation { name: "owner" } relation { name: "editor" userset_rewrite { union { child {_this {}} child {computed_userset { relation: "owner"}} }}} relation { name: "viewer" ... }
21. 01 02 03 04 05 06 07 08 09 10 11 12 type doc relations define owner as self define editor as self or owner define viewer as self or editor {u: "anne", r: "viewer", o: "doc:roadmap"} 01 02 03 Tuples Namespaces / Authorization Model Tuples #identiverse
22. 01 02 03 04 05 06 07 08 09 10 11 12 type doc relations define owner as self define editor as self or owner define viewer as self or editor Tuples #identiverse Request: check("anne", "editor", "doc:roadmap") --- Response: false {u: "anne", r: "viewer", o: "doc:roadmap"} 01 02 03 Tuples Namespaces / Authorization Model
23. 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 type doc relations define owner as self define editor as self or owner define viewer as self or editor Tuples #identiverse Request: check("anne", "viewer", "doc:roadmap") --- Response: true {u: "anne", r: "viewer", o: "doc:roadmap"} Tuples Namespaces / Authorization Model
24. 01 02 03 01 02 03 04 05 06 07 08 09 10 11 12 type doc relations define owner as self define editor as self or owner define viewer as self or editor type group relations define member as self Groups = Sets of users #identiverse Tuples Namespaces / Authorization Model
25. 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 type doc relations define owner as self define editor as self or owner define viewer as self or editor type group relations define member as self Groups = Sets of users #identiverse {u: "beth", r: "member", o: "group:a"} Tuples Namespaces / Authorization Model
26. Groups = Sets of users #identiverse 01 02 03 {u: "beth", r: "member", o: "group:a"} {u: "group:a#member", r: "editor", o: "doc:roadmap"} 01 02 03 04 05 06 07 08 09 10 11 12 type doc relations define owner as self define editor as self or owner define viewer as self or editor type group relations define member as self Tuples Namespaces / Authorization Model
27. Groups = Sets of users #identiverse 01 02 03 04 05 06 07 08 09 10 11 12 Namespaces / Authorization Model type doc relations define owner as self define editor as self or owner define viewer as self or editor type group relations define member as self Request: check("beth", "editor", "doc:roadmap") --- Response: true 01 02 03 Tuples {u: "beth", r: "member", o: "group:a"} {u: "group:a#member", r: "editor", o: "doc:roadmap"}
28. Groups = Sets of users #identiverse 01 02 03 04 05 06 07 08 09 10 11 12 Namespaces / Authorization Model type doc relations define owner as self define editor as self or owner define viewer as self or editor type group relations define member as self 01 02 03 Tuples {u: "beth", r: "member", o: "group:a"} {u: "group:a#member", r: "editor", o: "doc:roadmap"} Request: check("beth", "viewer", "doc:roadmap") --- Response: true
29. Relationships between objects #identiverse 01 02 03 Tuples 01 02 03 04 05 06 07 08 09 10 11 12 13 Namespaces / Authorization Model type doc relations define owner as self define editor as self or owner define viewer as self or editor or viewer from parent define parent as self type group relations define member as self type folder relations define viewer as self
30. 01 02 03 Tuples Relationships between objects #identiverse {u: "folder:2022", r: "parent", o: "doc:roadmap"} 01 02 03 04 05 06 07 08 09 10 11 12 13 Namespaces / Authorization Model type doc relations define owner as self define editor as self or owner define viewer as self or editor or viewer from parent define parent as self type group relations define member as self type folder relations define viewer as self
31. Relationships between objects #identiverse 01 02 03 {u: "folder:2022", r: "parent", o: "doc:roadmap"} {u: "cris", r: "viewer", o: "folder:2022"} Tuples 01 02 03 04 05 06 07 08 09 10 11 12 13 Namespaces / Authorization Model type doc relations define owner as self define editor as self or owner define viewer as self or editor or viewer from parent define parent as self type group relations define member as self type folder relations define viewer as selfa
32. Relationships between objects #identiverse 01 02 03 04 05 06 07 08 09 10 11 12 13 Namespaces / Authorization Model type doc relations define owner as self define editor as self or owner define viewer as self or editor or viewer from parent define parent as self type group relations define member as self type folder relations define viewer as selfa Request: check("cris", "viewer", "doc:roadmap") --- Response: true 01 02 03 {u: "folder:2022", r: "parent", o: "doc:roadmap"} {u: "cris", r: "viewer", o: "folder:2022"} Tuples
33. • Global Spanner • Distributed Cache • Special index for deep group nesting • Search with permissions • Reverse-indexable grammar • Ability to watch changes to build indexes Reliability & Latency #identiverse
34. #identiverse Getting Started
35. Pick an implementation #identiverse Open Source spicedb SaaS
36. Integrate #identiverse • Define your authorization model • SaaS provide tests/assertions for this, good to learn and iterate • Shadow writes and reads • Test for latency at scale • Optional: integrate with policies • Ship it :)
37. When to use Zanzibar like systems? #identiverse
38. • Enables secure, privacy friendly sharing and collaboration • More likely useful in B2B* or B2C scenarios Summary #identiverse
39. Things to look for • Flexible for new features • Low latency, reliable • Authorization data • Granular: does not fit in a token • Dynamic: changes often • Search with permissions #identiverse
40. Thank you! #identiverse
41. References #identiverse
42. • External consistency https://cloud.google.com/spanner/docs/true-time-external-consistency • Himeji Airbnb https://medium.com/airbnb-engineering/himeji-a-scalable-centralized-system-for-authorization-at-airbnb-341664924574 https://medium.com/airbnb-engineering/how-airbnb-supports-co-hosting-edfb11d88575 https://authorizationinsoftware.auth0.com/public/49/Authorization-in-Software-f9b69587/9ae303a5 • Spanner https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf • Carta Authz https://medium.com/building-carta/authz-cartas-highly-scalable-permissions-system-782a7f2c840f https://medium.com/building-carta/user-authorization-in-less-than-10-milliseconds-f20d277fec47 TODO: References (1) #identiverse
43. Appendix #identiverse
44. Can be done with more work • What subjects can perform action A on object O? (with nested groups) • What objects can subject S perform actions {A1, A2, …} on? Optimize for • Can subject S perform action A on object O? By-product • What subjects can perform action A on object O? (no nested groups) Design #identiverse
45. Global Spanner #identiverse
46. Distributed Cache #identiverse
47. Leopard #identiverse
48. Results returned by query Objects a user can access % of objects a user can access Example How to solve? LOW N/A N/A Search by title exact match MULTIPLE CHECKS HIGH HIGH (5k+) LOW/MEDIUM A company's Google Drive INDEX FROM WATCH + CHECK HIGH HIGH (5k+) HIGH Twitter Search MULTIPLE CHECK or INDEX FROM WATCH + CHECK N/A LOW (100) LOW/MEDIUM RETURN LIST OF OBJECTS N/A LOW (100) HIGH Not an FGA case MULTIPLE CHECKS Search #identiverse
49. Title of next section of this slide #identiverse
50. Title of next section of this slide #identiverse
51. This is a basic info slide. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. #identiverse
52. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. This is a basic info slide. #identiverse
53. Developer Requirements Insert session copy here •Insert session copy here. •Insert session copy here. •Insert session copy here. •Insert session copy here. #identiverse