3/ 0οΈβ£ Introduction
Zanzibar is a "Relationship based access control" (ReBAC) authorization system, i.e.: a user has access to an object if it has a particular relation to it.
Zanzibar stores (object, relation, user) "tuples" with data about these relations.
4/ To express that "anne@auth0.com" is an owner of the "RFC 100" doc a tuple like the following would be written:
5/ 1οΈβ£ Permission model flexibility
Objects often support many relations with users, e.g.: 'viewer' or 'editor' for a document.
Clients define a "namespace configuration" to specify the set of relations that users can have to objects of a type, and how those relations interact.
6/ To check if a user U has a relation R to an object O, clients call the"check" RPC :
check(O, R, U) returns bool
Zanzibar supports the following cases (this is a simplification):
- Direct: user itself has a relation to the object
7/ - Group: user belongs to a "group", the group has the relation to the object. However, groups are not a special construct. Group membership is defined by relations as well, e.g.:
{
"object": "group:auth0/admins"
"relation": "member"
"user": "beth@authh0.com"
}
8/ - Replace: given relation R1, if U has relation R1 to O, then it also has relation R. This is useful for concentric permissions such as: all writes are readers.
9/ - Indirect: allows expressing "viewers of the folder (parent) are viewers of all items in the folder (children)"
10/ 2οΈβ£ Auditing
The Zanzibar paper does not talk about auditing, but the model is audit friendly π:
- Namespace config changes can be both explicitly approved and logged
- Tuple writes can be logged as part of the write path, since writes are not latency sensitive
11/ - Checks can be (async) logged to determine who tried to access what, when
π Having consistently formatted logs come from a single system has many uses: anomaly detection and response, usage analysis, etc.
---
π We'll continue exploring the 3 remaining needs tomorrow
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
3/ You'd: 1. Sign up for a subscription 2. Configure who has access to what 3. Pick an SDK for your favorite language/tool 4. (optionally) Feed your authZ data from existing sources into #sandcastle
That's the ideal future. At this point you'd have AuthZ for your app π€―
We'll go over what is currently being addressed and what the gaps areπ
2/
As we've mentioned before, solving #fgaatscale requires:
1οΈβ£ Permission modelling flexibility
2οΈβ£ Auditing capabilities
3οΈβ£ Correctness: no invalid permissions are granted
4οΈβ£ Low Latency
5οΈβ£ High availability
3/ Solving #fgaatscale is becoming a need because:
βοΈ Users expect collaboration features in most products they used, and that requires FGA
βοΈ Increasing privacy and compliance regulations require companies in different verticals to restrict access as much as possible
3/ Like github, @googledrive has B2C and B2B models. However, @googledrive's sharing model is the same for B2C and B2B. The difference is who you can share files with.
In this thread explore we'll the problems of authorization at scale using a real world, well known example
2/ This is a key part of product development, especially when building infrastructure. We want to understand what our customers will eventually build with our service.
We also promised to unveil this week the problem we want to dive into π₯...
2/ The area we'd like to explore is: *fine-grained authorization*
Why this? And why now?π
3/ Large scale fine-grained authorization as a building block is an unsolved problem. Just like authentication was ~8 years ago. We implement it in every app we build, over and over. There is no generic, cross-platform, cross-domain solution.