Authorization is the process of determining if an authenticated user can access or perform an operation on a given resource. Role-based access control (RBAC) is the most well-known authorization model. With RBAC permissions are grouped into roles that are associated with users. While simple and straightforward, RBAC has disadvantages, especially at Google’s size and scale.

A new approach to authorization was needed to secure access to Google’s many services (e.g. Drive, YouTube, Gmail, etc.). Read on for a detailed account of Zanzibar, Google’s centralized access control system, or go here for example policies.

What Zanzibar offers

Zanzibar is Google’s centralized authorization system. It consolidates a wide range of access control policies used by many client services, including Calendar, Cloud, Drive, Maps, Photos, and YouTube. It is a highly scalable platform for creating, storing, and checking permissions. It allows for consistent and uniform access control across Google's many applications.

Zanzibar places users and their relationships with resources at the center, rather than roles or user attributes. Instead of asking “Is role A assigned to user X?”, as you would with role-based access control, Zanzibar poses the question: “What relationship does user X have with resource Y?”. The type of relationship the user has with the resource determines which actions are possible. For instance, user X belongs to a group that has access to a shared folder. The shared folder contains a document Y with edits allowed by any member of that group. To determine if X can edit the resource, you only need to follow the relationship links going from X to Y.

Zanzibar uses an authorization model called relationship-based access control (ReBAC). With this model, it authorizes, by its own account, access to services used by billions of people worldwide. These services involve trillions of access control lists (ACLs) with millions of authorization checks per second. It responds to 95% of authorization check requests in less than 10 milliseconds with +99.999% availability.

These astonishing results are possible due to a collection of technologies. A globally distributed database system, Spanner, is used to replicate the ACL data in ten data centers with loads distributed across thousands of servers. A consistency protocol ensures that access control decisions respect the order of changes to ACLs and resources. A simple configuration language allows for modeling relations between users and resources, including deep nesting. And a set of APIs offers the ability to:

1. Read and modify these relationships
2. Expand a complex nested set of relationships for visualization
3. Add or remove ACLs
4. Receive notification of ACL or relationship changes

The original paper by Google provides a detailed account of Zanzibar. It covers its features, architecture, and implementation.

The rest of this article explains two key features: relationships and consistency.

Modeling Relationships

ReBAC defines relationships that users (humans or accounts) have with objects in the system, as well as objects with other objects. This can capture complex relationships, which are possible when accessing nested objects. For example, a calendar item in an email with a meeting link.

Zanzibar’s relationship-based access control is best explained through an example, as shown in the image below.

Every Google service defines its type of objects using namespaces. So in our example, each resource type has a namespace (e.g. document, folder, group, etc). Specific resources (objects) are identified within those namespaces.

Starting with the left-hand side of the figure, we see a document X. The document type has four relationships: Owner, Editor, Viewer, and Parent. Alice is the Owner of document X and Bob is the Editor. Zanzibar’s configuration language expresses such relationships as a tuple of the form (user, relation, object). A query such as “Is Bob an editor of document X?” finds the tuple “[user=Bob] is [relation = an editor] of [object=document X]” to get a positive answer.

Note the directed, dashed arrow from Owner to Editor and then to Viewer. This models a hierarchy, where an Owner is also an Editor and Editors are Viewers of the document. So, to determine if Alice can edit the document, one has only to follow the links Alice -> Owner -> Editor-> DocX to return a "yes". Traversing the inherited relationships, we find that the answer to the question “What actions can Alice take on document X?” returns Owner, Editor, and Viewer.

The lower middle part of the figure models inheritance based on a parent-child relationship. Assume the usual policy that allows anyone who can view a folder to also view its contents. Then, if Jill is a viewer of folder Y, she can also view document X because folder Y has the parent relation to document X.

There are other objects in the example, which allow groups of users to have a relationship with an object. The right-hand side of the figure shows an object, Group: Z, that has several members, such as Bill. Every member of Group: Z, including Bill, has a Viewer relationship with document X.

Zanzibar has defined a simple, yet rich, configuration language for describing relationship tuples of the form: <object>#<relation>@<user>. Using this notation, our first example above is expressed as document:X#editor@Bob. A more complex example, such as the last one involving Bill, shows nesting users in groups: document:X#viewer@[group:Z#member@Bill]. These relationship tuples are stored as rows in a database with one for each namespace. This becomes the resource's access control list.

Maintaining Consistency

A critical requirement for access control systems is to respect the order of modifications and checks for permissions. This is meant to prevent false positives and false negatives. A false positive would be when a user is allowed to perform an action even if the permission to do so has been revoked. A false negative is when a user is prevented from performing an action even after permission has been granted.

The likelihood of false positives and negatives increases with distributed data. Distributed data prevents simultaneous updates of the entitlement data in all replicas. A delayed permission revocation update may happen after an access check so a user with revoked permission poses a security threat.

Zanzibar solves this problem through close cooperation between itself and the service using it. It uses a common clock – TrueTime – on all database replicas to timestamp (with microsecond resolution) any ACL or resource update. This is a part of Spanner, the database used by Zanzibar, which offers a unified view of the distributed data.

The consistency protocol uses a special cookie, called Zanzibar’s cookie or zookie. A zookie is an opaque data structure that encapsulates a timestamp for each ACL or resource update. Zanzibar returns a zookie to the service when acknowledging an update. The zookie codifies the time of the last update so that later checks should use ACL data created after that time to determine access. This prevents both applying old ACLs to new content, as well as misordered updates to the ACL. The figure below shows how using zookies prevents misordered ACLs.

The first exchange above shows that Alice removes Bob from viewing a folder. This also removes his ability to view the documents within that folder. Zanzibar acknowledges the ACL update with a zookie encapsulating the update commit time, T0, which the service stores. The zookie codifies the requirement that any ACL checks in the future should use data created after time T0.

Later, as shown in the second exchange, Charlie wants to add a new document to the folder. An ACL check checks with Zanzibar if Charlie has the appropriate permission to do so. The request includes the zookie stored from the previous exchange, which Zanzibar uses to verify that the last ACL update happened before this request. This is how the system verifies that the ACL is still fresh and reflects the permissions at time T1. A new zookie, encapsulating the timestamp when the new content was created and recorded in the ACL, accompanies the response and is stored by the service.

When Bob attempts to view the new document, Zanzibar uses the latest stored zookie included in the check request to deny permission. The ACL check uses data created after time T1 and by then Bob’s permission to view the folder content was revoked.

Conclusion

Why should we care about Zanzibar? Given the enormous reach of Google, Zanzibar is proof that it is possible to build a common authorization solution with high availability, low latency, and the flexibility to deliver fine-grained access control.

Many organizations have chosen to build their authorization solutions using principles inherited from Zanzibar. Some aspects have been open-sourced, like OpenFGA and Topaz, a fine-grained authorization system that lets organizations combine Zanzibar with Open Policy Agent (OPA).

There are SaaS offerings from vendors, such as Aserto, that allow organizations to deploy Zanzibar-like authorization solutions, without building up Google-level data consistency expertise. What sets Aserto apart is the ease with which developers can add ReBAC, as well as mix RBAC, ABAC, and ReBAC-style authorization models, allowing them to combine the best of both worlds.

As always, we are here to help! So feel free to contact us with any questions you might have, or schedule a time to speak with an engineer about your specific authorization challenges.