Part 5 · 2 chapters · ~12 min

Zanzibar-Style Authorisation

Google Zanzibar's model of relationship tuples, schemas and checks, consistency tokens and the new-enemy problem, OpenFGA and SpiceDB, list and reverse queries ("what can Ada see?"), keeping tuples in sync with application data, and performance.

11

Tuples, schemas and checks

code
# OpenFGA model
model
  schema 1.1
type user
type team
  relations
    define member: [user]
type workspace
  relations
    define owner: [team#member]
    define viewer: [user] or owner
type account
  relations
    define parent: [workspace]
    define view: viewer from parent

# write tuples when the app changes, check at request time
fga tuple write team:risk member user:ada
fga query check user:ada view account:81      # allowed: true
ZANZIBAR-STYLE AUTHORISATION
relationship tuples and a schema that derives permissions
tupleteam:risk#member@user:adatupleworkspace:ng#owner@team:risk#membertupleaccount:81#parent@workspace:ngschemaaccount.view = parent->viewercheckcan user:ada view account:81?answeryes, via 3 hops
swipe the figure sideways, or tap expand for full screen
1/5
tuples
Facts are stored as relationship tuples: object#relation@subject. Ada is a member of the risk team; the risk team's members own the Nigeria workspace; account 81 belongs to that workspace.
object#relation@subjectfacts, not permissions
12

Sync, listing and performance

challengeapproach
keeping tuples in sync with the app databasewrite tuples in the same workflow (outbox to the authz service), and reconcile periodically
"list everything Ada can view"ListObjects APIs, or materialised permission indexes for large lists, filtered in the database query
latencycheck calls in parallel, cache with short TTLs, use consistency tokens only where freshness matters
auditingtuples are an audit trail of who granted what; keep change history