Summary
Authorization as a Service (AAS) is based on the Google Zanzibar whitepaper. The publication in 2019 inspired companies like AirBnB and Carta to build their own internal authorization systems in its image.
The fundamental unit of data in Zanzibar is the relation tuple. A relation tuple defines a relation between an object and a user. This manifests in the way that Zanzbar represents authorization data.
Zanzibar lets you express object-object relationships, like the relationship between a document and its containing folder. This is a pretty fundamental notion in authorization, but it required diverging from the rigid relation tuples definition. Even with this revision, there remain things that you just can’t express with relation tupling.
This is how Zanzibar expresses authorization logic: as rules that define relations in terms of other relations. There are three: owner, editor, and viewer. The configuration provides a userset_rewrite directive that allows clients to construct usersets from other usersets.
When you authorize a request, the question you need to answer is “does this user have permission to perform this action on this resource?” With Zanzibar and systems that are based on it, you can’t ask that question. Instead, you have to rephrase it as “ does this user has this relation on this object?’
Relationships are the wrong abstraction for authorization. Your authorization service only lets you define relations. So you just pretend permissions are relations and get on with your day. This is essentially the same thing as creating a relation for every authorized action.
When the thing you’re trying to write is a silly poem, that isn’t a big deal. But when it’s your application’S authorization policy, the consequences of not being able to say what you mean are more severe.
