$30 off During Our Annual Pro Sale. View Details »

Deep Dive Into Google Zanzibar and its Concepts for Authorization Scenarios

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.

Damian Schenkelman

June 24, 2022
Tweet

More Decks by Damian Schenkelman

Other Decks in Programming

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