Chapter 25 — Distributed authorization: RBAC to ABAC to ReBAC/Zanzibar

Practice (75 min)

1. Run OpenFGA (or SpiceDB). Model SecureShop's order-viewing rules above. Load tuples. Run check and list-objects for several user/order/tenant combinations; get the deny cases right.
2. Add a hierarchy: folder/collection of orders with inherited viewer. Verify inheritance and that removing the parent relation revokes access.
3. Wire a PEP into a tiny orders-api: extract sub from the (Ch 24) token, call check, enforce, return 404 on deny. Measure the added latency; add a short-TTL cache; re-measure.
4. Demonstrate the "new enemy" problem: revoke bob's shared_viewer, then immediately check against a stale cache — show the leak; then use the engine's consistency token (zedtoken/consistency) to fix it.
5. Keep the tuple store in sync via events: emit order.shared / order.unshared / agent.added events and have a consumer write/delete tuples. Prove eventual consistency and bound the lag.
6. Run the same rules as a Cedar policy set and as OPA/Rego for comparison; note which model expresses "shared with" and "agent from tenant" most naturally.

Build it in Go (45 min) — a Zanzibar-style check in about 120 lines

The essence of ReBAC fits in one function: permissions are computed from relationship tuples plus a few rewrite rules (an editor is also a viewer, and a folder's viewers can view its documents), and the check returns the chain of tuples that proves the answer.

// rebac: relationship-based access control, Zanzibar style, in ~120 lines.
//
// Permissions are derived from stored RELATIONSHIP TUPLES
//
//	object#relation@subject          e.g.  doc:q3-plan#editor@user:bob
//
// plus a small schema of REWRITE RULES:
//
//	viewer  = direct viewers + editors          (every editor can view)
//	editor  = direct editors + owners
//	on docs, viewer also = viewers of the PARENT folder
//
// Subjects can be users or USERSETS:  group:eng#member  ("every member of eng").
//
//	go run ./rebac
package main

import (
	"fmt"
	"slices"
	"strings"
)

type tuple struct{ object, relation, subject string }

type store struct{ tuples []tuple }

// parse splits "doc:q3-plan#editor@user:bob" (the subject may itself contain '#').
func parse(t string) tuple {
	obj, rest, _ := strings.Cut(t, "#")
	rel, sub, _ := strings.Cut(rest, "@")
	return tuple{obj, rel, sub}
}

func (s *store) write(t string) { s.tuples = append(s.tuples, parse(t)) }

// delete revokes access: no ACL scan, no cache to invalidate by hand.
func (s *store) delete(t string) {
	s.tuples = slices.DeleteFunc(s.tuples, func(x tuple) bool { return x == parse(t) })
}

// schema: which other relations on the same object imply this one, and which
// relation on a related object ("tupleset") passes through.
var implied = map[string][]string{
	"viewer": {"editor"},
	"editor": {"owner"},
}
var inherited = map[string][2]string{ // relation -> {link relation, relation on the linked object}
	"viewer": {"parent", "viewer"}, // viewer of a doc's parent folder can view the doc
	"editor": {"parent", "editor"},
}

// check answers "does subject have relation on object?" and returns the
// chain of tuples that proves it (or nil). depth bounds recursion on cycles.
func (s *store) check(object, relation, subject string, depth int) []string {
	if depth > 10 {
		return nil
	}
	for _, t := range s.tuples {
		if t.object != object || t.relation != relation {
			continue
		}
		if t.subject == subject { // direct grant
			return []string{fmt.Sprintf("%s#%s@%s", t.object, t.relation, t.subject)}
		}
		if grp, rel, ok := strings.Cut(t.subject, "#"); ok { // userset: group:eng#member
			if why := s.check(grp, rel, subject, depth+1); why != nil {
				return append([]string{fmt.Sprintf("%s#%s@%s", t.object, t.relation, t.subject)}, why...)
			}
		}
	}
	for _, rel := range implied[relation] { // e.g. editors are viewers
		if why := s.check(object, rel, subject, depth+1); why != nil {
			return append([]string{fmt.Sprintf("(%s implies %s)", rel, relation)}, why...)
		}
	}
	if inh, ok := inherited[relation]; ok { // e.g. viewers of the parent folder
		for _, t := range s.tuples {
			if t.object == object && t.relation == inh[0] {
				if why := s.check(t.subject, inh[1], subject, depth+1); why != nil {
					return append([]string{fmt.Sprintf("%s#%s@%s", t.object, t.relation, t.subject)}, why...)
				}
			}
		}
	}
	return nil
}

func main() {
	s := &store{}
	for _, t := range []string{
		"folder:finance#owner@user:alice",
		"folder:finance#viewer@group:auditors#member",
		"group:auditors#member@user:carol",
		"doc:q3-plan#parent@folder:finance",
		"doc:q3-plan#editor@user:bob",
	} {
		s.write(t)
	}

	for _, q := range [][3]string{
		{"doc:q3-plan", "viewer", "user:bob"},
		{"doc:q3-plan", "editor", "user:alice"},
		{"doc:q3-plan", "viewer", "user:carol"},
		{"doc:q3-plan", "editor", "user:carol"},
		{"doc:q3-plan", "viewer", "user:mallory"},
	} {
		why := s.check(q[0], q[1], q[2], 0)
		verdict := "DENY "
		if why != nil {
			verdict = "ALLOW"
		}
		fmt.Printf("%s  %-12s %-6s %-12s", verdict, q[2], q[1], q[0])
		if why != nil {
			fmt.Printf("  because %s", strings.Join(why, " -> "))
		}
		fmt.Println()
	}

	// Revocation is just deleting a tuple: remove carol from auditors.
	s.delete("group:auditors#member@user:carol")
	fmt.Printf("\nafter removing carol from group:auditors: carol can view q3-plan? %v\n",
		s.check("doc:q3-plan", "viewer", "user:carol", 0) != nil)
}

$ go run ./rebac
ALLOW  user:bob     viewer doc:q3-plan   because (editor implies viewer) -> doc:q3-plan#editor@user:bob
ALLOW  user:alice   editor doc:q3-plan   because doc:q3-plan#parent@folder:finance -> (owner implies editor) -> folder:finance#owner@user:alice
ALLOW  user:carol   viewer doc:q3-plan   because doc:q3-plan#parent@folder:finance -> folder:finance#viewer@group:auditors#member -> group:auditors#member@user:carol
DENY   user:carol   editor doc:q3-plan
DENY   user:mallory viewer doc:q3-plan

after removing carol from group:auditors: carol can view q3-plan? false

What to notice:

• Every ALLOW comes with its proof. "Why can Carol see this?" is the question auditors and incident responders ask. A policy engine that can't answer it is hard to operate.
• Revocation is a single tuple delete. No per-document ACLs to scan, and no role table to diff.
• Alice never had a grant on the document. Ownership of the parent folder flowed down through two rewrite rules. That's also the risk: a broad tuple high in the hierarchy grants a lot, so review those tuples like IAM policies.
• What production systems (SpiceDB, OpenFGA) add: consistency tokens ("zookies") so a check never misses a revocation it should have seen, caching, expand and lookup queries, and a schema language instead of Go maps.

Exercises:

1. Add tenant isolation as a relation: every object #tenant@tenant:acme, and make viewer require membership of the object's tenant. Prove a cross-tenant check fails even with a direct grant (Chapter 27).
2. Implement lookupResources(user, relation): every document a user can view. Why is this much harder than check?
3. Add a cycle (group:a#member@group:b#member, and the reverse) and confirm the depth limit stops it.