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
   

   View Slide

2. Principal Architect at Auth0/Okta
   Damian Schenkelman
   #identiverse
   

   View Slide

3. Agenda
   #identiverse
   • Authorization Background
   • Intro to Zanzibar
   • How it works
   • How to get started
   • When to use it
   

   View Slide

4. Authorization
   #identiverse
   

   View Slide

5. For scale:
   • Access Review
   • Change Management
   • Auditable
   • Reliable
   • Fast
   Developer Requirements
   #identiverse
   

   View Slide

6. Typical Approaches
   #identiverse
   

   View Slide

7. Too coarse, imagine Instagram
   with role "Picture Viewer"
   Role Explosion
   Token bloat
   RBAC
   #identiverse
   

   View Slide

8. ABAC
   #identiverse
   01
   02
   03
   04
   05
   06
   07
   08
   09
   enum Decision {
   Allow,
   Deny,
   …
   }
   Decision {policyName}(sub, action, obj, ctx) {
   …
   }
   

   View Slide

9. #identiverse
   ABAC Architecture
   

   View Slide

10. How ABAC meets Dev Requirements
    #identiverse
    For scale
    Access Review
    Change Management
    Auditable
    Reliable
    Fast
    

    View Slide

11. Google Zanzibar
    #identiverse
    

    View Slide

12. Used for
    #identiverse
    

    View Slide

13. Middle ground
    #identiverse
    Google Zanzibar
    (Authorization "as a Service” )
    DBaaS
    (handles data)
    Policies
    (Authorization needs)
    

    View Slide

14. Relationship based access control (ReBAC)
    #identiverse
    

    View Slide

15. "Does user S have
    relationship A to object O?"
    "Can subject S perform
    action A on object O?"
    Rephrase the question
    #identiverse
    

    View Slide

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?"
    

    View Slide

17. How do Zanzibar-like
    systems work?
    #identiverse
    

    View Slide

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"
    ...
    }
    

    View Slide

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"
    ...
    }
    

    View Slide

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"
    ...
    }
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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"}
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

34. #identiverse
    Getting Started
    

    View Slide

35. Pick an implementation
    #identiverse
    Open Source
    spicedb
    SaaS
    

    View Slide

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 :)
    

    View Slide

37. When to use Zanzibar
    like systems?
    #identiverse
    

    View Slide

38. • Enables secure, privacy friendly sharing and collaboration
    • More likely useful in B2B* or B2C scenarios
    Summary
    #identiverse
    

    View Slide

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
    

    View Slide

40. Thank you!
    #identiverse
    

    View Slide

41. References
    #identiverse
    

    View Slide

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
    

    View Slide

43. Appendix
    #identiverse
    

    View Slide

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
    

    View Slide

45. Global Spanner
    #identiverse
    

    View Slide

46. Distributed Cache
    #identiverse
    

    View Slide

47. Leopard
    #identiverse
    

    View Slide

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
    

    View Slide

49. Title of next section of
    this slide
    #identiverse
    

    View Slide

50. Title of next section of
    this slide
    #identiverse
    

    View Slide

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
    

    View Slide

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
    

    View Slide

53. Developer Requirements
    Insert session copy here
    •Insert session copy here.
    •Insert session copy here.
    •Insert session copy here.
    •Insert session copy here.
    #identiverse
    

    View Slide