1/ Back after last week's break 😴, ready to talk about why we picked the "Zanzibar model" for project #sandcastle: πŸ‘‡
2/ We've shared the 5 things needed to solve #fgaatscale

Let's explore high-level how "Zanzibar" works and how it meets those needs

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:

"object": "RFC 100"
"relation": "owner"
"user": "anne@auth0.com"
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. Image
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)"

This simple, yet powerful model powers authorization for @googledrive @YouTube @googlecloud and more!
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

Keep Current with The Auth0 Lab

The Auth0 Lab Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @Auth0Lab

3 Dec 20
1/ Let's continue exploring how the "Zanzibar" model allows us to solve #fgaatscale πŸ‘‡

3️⃣ Correctness: no invalid permissions are granted

To provide "correct" answers, an ACL check needs to always read a "valid view" of the system.
2/ "Valid" means: the full state read from storage should have existed at a "logical point in time" and includes all committed records at that point.

The picture provides a counterexample, a request should not read two different values from a namespace at different reads. Image
3/ Similarly, new tuples should not "show up" in a request's query replies while it executes.

This applies to:
- in progress transactions
- records committed in the lifetime of the request

Summarizing: reads should be consistent at a "logical timestamp" within a request.
Read 10 tweets
18 Nov 20
1/ We've analyzed the #fgaatscale problem:

We've shared our view on the market:

It's time to tell you what we are planning to build πŸ₯... 🧡
2/ Project #sandcastle will be a globally distributed, highly reliable service for large scale, fine grained authorization.

It's based on @Google's Zanzibar paper: research.google/pubs/pub48190/, that powers #fgaatscale for @googledrive @googlecloud @YouTube and @Google other products!
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 🀯
Read 8 tweets
11 Nov 20
1/ Having analyzed the @github and @googledrive #fgaatscale cases, we'll share our view on the authz market.

We'll go over what is currently being addressed and what the gaps areπŸ‘‡
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
Read 21 tweets
10 Nov 20
1/ Last week we did a deep dive of @github's authorization model and the problems they solve

In this thread we'll focus on another well known product: @googledrive a great example of a collaboration platform.

πŸ“ŠHow is gdrive "authorization at scale"?
2/ Well, in 2018 they:
- hit 1B users
- 2 trillion files


πŸ” Review their permission model
πŸ”Go over their "search" story and how authz fits in it
🎯Analyze examples of why "correctness" () is important
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.
Read 21 tweets
5 Nov 20
1/ Last time explained why we are exploring fine grained authorization:

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.

Our analysis case is @github.
3/ @github is an interesting example as it’s a *collaboration* platform built on top of git.

We believe collaboration and authorization are two sides of the same coin
Read 19 tweets
30 Oct 20
1/ On Wed, we posted about why we are doing this and what we expect.

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.
Read 8 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!