generated from coulomb/repo-seed
tegwick
1c1b5c9bc6
Backfill all 23 research source notes with terminology extracts, modeling assumptions, conflicts, canonical mappings, and references. Refresh terminology artifacts, refine the conceptual model with explicit scenario paths, reconcile canon surfaces and open questions, and mark the workplan finished.
111 lines
4.8 KiB
Markdown
111 lines
4.8 KiB
Markdown
# Google Zanzibar ReBAC
|
|
|
|
## Source Type
|
|
|
|
Architecture pattern and research paper. Google Zanzibar (2019) defines
|
|
relationship-based access control at global scale.
|
|
|
|
## Domain
|
|
|
|
Relationship-based authorization, permission inheritance, and large-scale
|
|
access control graphs.
|
|
|
|
## Why This Source Matters
|
|
|
|
Zanzibar/OpenFGA-style relationship tuples are especially close to what
|
|
identity-canon needs for memberships, ownership, representation, delegation,
|
|
and tenant administration.
|
|
|
|
Zanzibar is the reference architecture for storing authorization facts as
|
|
subject-relation-object tuples with computed permission expansion.
|
|
|
|
## Key Concepts
|
|
|
|
- **Relation tuple**: `object#relation@subject` or `object#relation@subject#subject_relation`.
|
|
- **Object**: typed entity with namespace and ID (e.g., `document:readme`).
|
|
- **Subject**: user, group, or object acting through a relation.
|
|
- **Relation**: named edge type on an object type (owner, editor, viewer, member).
|
|
- **Userset rewrite**: computed relations via union, intersection, exclusion,
|
|
and arrow operators (e.g., parent->owner).
|
|
- **Namespace configuration**: schema defining object types, relations, and
|
|
rewrite rules.
|
|
- **Check API**: evaluate whether subject has relation to object.
|
|
- **Expand API**: enumerate subjects with relation to object.
|
|
- **zookie**: consistency token for read-after-write semantics.
|
|
- **Group as subject**: usersets allow group-like indirection in tuples.
|
|
|
|
## Relevant Terminology
|
|
|
|
| Term | Source meaning |
|
|
| --- | --- |
|
|
| Tuple | Stored authorization fact. |
|
|
| Object | Resource or entity being authorized. |
|
|
| Subject | Actor or userset granted a relation. |
|
|
| Relation | Named permission edge on object type. |
|
|
| Userset | Indirect subject reference via relation chain. |
|
|
| Namespace | Schema for object types and relations. |
|
|
| Check | Boolean permission query. |
|
|
| Expand | Enumerate authorized subjects. |
|
|
| owner / editor / viewer | Common relation names (deployment-specific). |
|
|
| parent relation | Hierarchical inheritance via rewrite rules. |
|
|
|
|
## Modeling Assumptions
|
|
|
|
- **Authorization facts are relationships**, not role assignments on users alone.
|
|
- **Subjects and objects are typed strings**, not rich identity records.
|
|
- **Inheritance is computed** from tuple graph via rewrite rules.
|
|
- **Identity provisioning is external**; Zanzibar stores authorization state only.
|
|
- **Groups are modeled as objects** with member relations, not as separate IAM groups.
|
|
- **Consistency matters** for distributed reads (zookie tokens).
|
|
- **No canonical person model**; subject IDs are opaque.
|
|
|
|
## Identity-Canon Implications
|
|
|
|
- Zanzibar **tuple** maps to **Relationship Tuple** (authorization projection).
|
|
- **Object** maps to **Authorization Resource** projection.
|
|
- **Subject** maps to **Authorization Principal** projection.
|
|
- **Relation** maps to typed **Relationship** with authorization implication.
|
|
- **Namespace** maps to **Authorization Domain** Scope.
|
|
- **Userset rewrite** is authorization engine logic, not canonical identity.
|
|
- Membership tuples (`group:eng#member@user:alice`) parallel **Membership
|
|
Relationship** but live in authz layer.
|
|
- Supports S05 (admin delegation), S08 (moderator relations), S10 (service
|
|
account acting for org via tuple).
|
|
|
|
## Terminology Conflicts
|
|
|
|
- **Subject**: Zanzibar subject is authz participant; OIDC subject is identifier.
|
|
- **Object**: Zanzibar object is authz resource; grammar object ≠ domain object.
|
|
- **Relation vs. Relationship**: Zanzibar relation is permission edge; canon
|
|
Relationship is broader (social, legal, operational).
|
|
- **Member**: Zanzibar member relation on group object ≠ social membership.
|
|
- **User**: Zanzibar user ID is opaque; no person/account distinction.
|
|
|
|
## Candidate Canonical Mappings
|
|
|
|
| Zanzibar concept | Candidate canonical concept |
|
|
| --- | --- |
|
|
| Relation tuple | Relationship Tuple (authorization projection) |
|
|
| Object | Authorization Resource |
|
|
| Subject | Authorization Principal |
|
|
| Relation name | Relationship type (authz-implied) |
|
|
| Namespace config | Authorization Domain Scope |
|
|
| Group object + member | Group + Membership (authz projection) |
|
|
| Userset rewrite | Authorization engine derivation (non-canonical) |
|
|
| zookie | Consistency metadata (operational) |
|
|
|
|
## Open Questions
|
|
|
|
- Should canonical Membership Relationship be shared between identity and
|
|
authz layers, or always projected into tuples?
|
|
- How should representation/delegation map to Zanzibar relations vs. identity-layer
|
|
Representation Relationship?
|
|
- Should object namespace prefixes map to Scope identifiers?
|
|
- When does a social Following relationship warrant an authz tuple vs. remain
|
|
identity-only?
|
|
|
|
## References
|
|
|
|
- Google Zanzibar paper — https://research.google/pubs/pub48190/
|
|
- Zanzibar ACL language (related) — referenced in paper §2
|
|
- OpenFGA (Zanzibar-inspired OSS) — https://openfga.dev/docs |