Zanzibar

Around the early 2010s, Google faced significant challenges related to scalable access control for its growing suite of services, such as Google Drive, Photos, Calendar, and YouTube. Each product needed to manage access in a consistent and efficient way, but existing solutions were fragmented, inconsistent, and did not meet the scaling needs.

In response to these challenges, Google started working on what would become "Zanzibar". The aim was to create a highly scalable, low-latency access control system that could support Google’s complex and diverse products.

In 2019, Google published a research paper titled "Zanzibar: Google’s Consistent, Global Authorization System".

The paper detailed the core principles and architecture of the Zanzibar system, and brought significant attention to how advanced access control systems can be architected to handle the challenges of modern applications

---

Zanzibar represents permissions as tuples that define relationships. For instance, user Alice has a viewer relationship with file Weekly Report

A tuple takes the form of <resource>#<relation>@<entity>

Where:

• <resource> is the object to which access is being controlled.

• <relation> is the type of access relationship (e.g., viewer, editor, owner).

• <entity> is the user or group involved in the relationship.

This tuple-based model can be thought of as a graph where nodes represent users, groups, and resources, while edges represent relationships like ownership, membership, or permissions.

Zanzibar can indeed be associated with Access Control Lists (ACLs), though it goes far beyond traditional ACLs in terms of capability and flexibility, allowing to determine not just direct permissions but also permissions inherited from group memberships.

Zanzibar is actually better associated with the Relationship-Based Access Control (ReBAC) model, which defines access through relationships between users, resources, and roles.