We successfully used a Relationship-based Authorization System based on the Zanzibar paper at my last job building a B2B SaaS leaning heavily on cross-company integration.
The flexibility in defining rules through tuples helped us iterate rapidly on new product features. We used self-hosted Ory Keto [0] instances as the implementation, though we would have preferred a managed solution. We were checking out Auth0 Fine Grained Authorization [1] but it was still in Alpha back then.
> though we would have preferred a managed solution
We completely agree here, which is why we initially started out with our managed cloud offering, Warrant Cloud[1]. While Zanzibar is powerful, operating it with solid latency/availability can be quite challenging.
Can anybody explain me why there seem to be much focus on scalability in this context? I mean we have 8 billion people. If the whole planet registers, home PC can handle it, plus it partitions beautifully if necessary in case of authentication. So what am I missing?
Very happy to see industry discover the power of graphs and especially, a triple-based representation (cf. RDF [0]; subjects are “subjects”, relationships are “predicates”, and objects are “objects”).
Now, a genuine question: why try to shoehorn a freeform graph (because the list of relationships is not hardcoded) into a relational DB instead of using a graph DBMS like Neo4j, Apache Jena (Fuseki) etc. From looking at the source code briefly [1], I didn’t see any extreme SQL optimizations. This indicates to me that Warrant would either support a very limited set of query types, or be very slow on quite a few types of them. Also see “billion triple challenge” in the academia around this.
Is Neo4j a good option? I've not heard great things about it performance-wise, though this was some years ago when tinkerpop/gremlin was starting to make news in my circles, and we were operating on extremely dense graphs.
The Zanzibar paper has a section on the consistency model, which says that the race conditions outlined are solved by respecting update order. It then solves it by using Spanner as underlying storage (which is kind of lazy).
You've highlighted a very important part of the paper. A lot of the external consistency guarantees provided by Zanzibar are facilitated by Spanner and its TrueTime mechanism. Warrant doesn't currently support/use Spanner. However, for the databases we do support (MySQL and Postgres - which are both ACID compliant), we've implemented the zookie protocol using the incrementing transaction ids they provide. This approach works for single writer deployments of these databases, so know that write throughput and overall availability will be lower. We started with this approach because most teams still use MySQL/Postgres. Warrant is built to support running on different types of databases, so we will be working on support for Spanner and other multi-writer distributed databases like Cockroach and Yugabyte in the future. I hope that helps.
The fact they did it that way is actually a perfect example of why Google is considered so far ahead of competitors technologically and operationally by their engineers. When you have a powerful building block like Spanner that engineers can use, they then can work on the product instead of wasting time on brittle consistency models, custom storage layers, and providing their own uptime guarantees.
This goes for every part of their stack. As a result, things like Colossus, BigTable, and Spanner effectively act like force multipliers for their engineers, because they provide the guarantees they can't get elsewhere. The fact other people at other random companies can't do that? Not their problem in the slightest, actually.
One thing I find difficult using access control systems as a distributed service like Zanzibar is a convenient and performant way to search and filter resource data using permissions. For example defining database queries that should only return resources a subject has access to based on Zanzibar permissions.
At Google, I believe some client applications build and maintain "permission-aware" search indexes based on the permissions in Zanzibar. In essence, Zanzibar can be queried to figure out the object ids a particular subject has access to. These object ids can then be hydrated via a database query or separate service call.
At Warrant, we're experimenting with allowing customers to maintain searchable metadata in Warrant and exposing a "query" API[1] that can automatically hydrate objects based on that metadata.
SpiceDB/Authzed has "Lookup"s. There's LookupResources for finding what a user has access to, and LookupSubjects now too to see who has access to a resource. Great capability. https://authzed.com/blog/lookup-subjects
Same reason I didn't invest much in this field yet.
When you access one resource it's fine to a do a roundtrip, but with listing, filtering, searching if you don't join at query time it doesn't work. I'm not entirely sure how they achieve it and I found it annoying that it's never mentioned because it's very common.
> Over the last couple years, authorization (AKA “authz”) has become a hot topic of debate. Proponents of various authz frameworks, libraries, and philosophies have voiced their opinions on how it should be implemented, jockeying for position to become the de facto way to implement authz
As a developer of a tiny internal webapp - this is fascinating to read! I like to keep things as simple as possible, but as with anything our scope and use cases have grown over time.
Our authzn can handle some of this stuff - our rules, built atop our org's existing IAM, are very similar to these directed relationship tuples - but as we need to grow that out any further I'm excited to look into which aspects of ReBaC we're still missing.
> A Flexible, Uniform Data Model for Authorization
Are there good examples of similar applications of data modules for similarly niche use cases? I get that there are obviously endless data models, but this seems to extend beyond that into a more integrated concept and I don’t quite know why that seems to be the case.
I think GraphQL might be a good example. Some might not consider it to be very niche, but its intention is to consolidate dependent API queries such that the client can fetch all the data it needs in a single request. In both Zanzibar and GraphQL, the idea behind the schema/modeling language is to provide a layer where logic specific to relationships between data (in the case of GraphQL) or logic specific to authorization (in the case of Zanzibar) can be specified such that neither the server nor the client need to worry about it and can instead query for data in a simpler way.
Zanzibar evaluates recursively, where AWS IAM is single-pass.
So AWS groups do not nest, but Zanzibar groups do. In Zanzibar a relation on an object (an implicit set of users) can be the subject of a rule; you can define “users who have editor permission on an object also have viewer permission” in one rule. This isn’t possible in AWS; there is no way to reference the set of principals who are allowed a particular action or policy.
I think that AWS policies tend to have a lot of duplicate rules because of lacking recursion. Zanzibar rules should be easier to maintain and audit.
AWS IAM is also just quite “hairy” from gradual evolution over the years. On the other hand, Zanzibar has a clean model.
It would be nice to have a compiler that would emit AWS IAM Policies given Zanzibar-style rule tuples.
These services aren’t really going after the same problems.
Zanzibar is a Google-internal implementation of the concepts outlined in this paper, focused on managing authorization as a function of relationships between objects.
AWS IAM is primarily for AAA services with AWS, though you can use it with AWS Identity Center to provide SSO to other systems via IAM.
Yet another Zanzibar system emerges. There's no functional advantage to using this system over any of the others, and the others aren't necessary either for the vast majority of needs.
Zanzibar is overkill for the majority of needs and introduces far too much complexity. It is the solution that covers scenarios of the likes in which you will never see. You will never grow into needing them, either. It is the pinnacle of over engineered software. The reason why people form companies offering it as a solution is to try to recover hundreds of hours of effort cost on something they didn't need.
Another interesting feature of capability-based systems (that is outside Zanzibar's scope) is that capabilities can themselves be used to gain access to an object. This is because they are unforgeable tokens, meaning they essentially have authentication baked into them. Zanzibar leaves the authentication piece to an external service and focuses on providing the ability to define, store, and query access rights for subjects.
As I understand it, "capabilities" in capability-based schemes uniquely reference an object and specify a list of access rights on that object. This seems fairly similar to tuples in Zanzibar, which reference a unique object, an access right, and a unique subject whom the access right belongs to. You can think of Zanzibar as a layer used for defining, storing, and querying for capabilities.
Google doesn't actually offer Zanzibar as a product/service (in GCP or otherwise) to customers. However, they do use it internally to manage permissions across their various products (Google Docs, Drive, YouTube, etc.) and have had a lot of success doing so. Because of that, there are many open source implementations of Zanzibar out there (as others have commented). Warrant also maintains our own open source implementation of Zanzibar[1] which powers our managed cloud offering, Warrant Cloud[2].
If you genuinely aren't trying to be snarky, then what was the point of this post? You clearly don't even know what Zanzibar is. If you were trying to find out more about it there would be hundreds of more useful questions to ask.
The actual implementation is closed source. The backing idea is described in the inaugural paper which third parties have used to build hosted and open source alternatives that you can try.
This tired trope has jumped the shark with this comment. Not only is it off topic, but even if it did refer to an actual Google product, it's disingenuous because its only point was to be snarky.
AndreasHae|2 years ago
The flexibility in defining rules through tuples helped us iterate rapidly on new product features. We used self-hosted Ory Keto [0] instances as the implementation, though we would have preferred a managed solution. We were checking out Auth0 Fine Grained Authorization [1] but it was still in Alpha back then.
[0]: https://www.ory.sh/keto/ [1]: https://auth0.com/developers/lab/fine-grained-authorization
kkajla|2 years ago
We completely agree here, which is why we initially started out with our managed cloud offering, Warrant Cloud[1]. While Zanzibar is powerful, operating it with solid latency/availability can be quite challenging.
[1] https://warrant.dev/
comboy|2 years ago
arekkas|2 years ago
Ory does have a managed service offering now for Ory Keto as well!
smarx007|2 years ago
Now, a genuine question: why try to shoehorn a freeform graph (because the list of relationships is not hardcoded) into a relational DB instead of using a graph DBMS like Neo4j, Apache Jena (Fuseki) etc. From looking at the source code briefly [1], I didn’t see any extreme SQL optimizations. This indicates to me that Warrant would either support a very limited set of query types, or be very slow on quite a few types of them. Also see “billion triple challenge” in the academia around this.
Good luck with your startup!
[0]: https://www.w3.org/TR/rdf11-primer/
[1]: https://github.com/warrant-dev/warrant/tree/main/pkg/authz/o...
zdragnar|2 years ago
susscrofa|2 years ago
How does Warrant deal with consistency?
kkajla|2 years ago
aseipp|2 years ago
This goes for every part of their stack. As a result, things like Colossus, BigTable, and Spanner effectively act like force multipliers for their engineers, because they provide the guarantees they can't get elsewhere. The fact other people at other random companies can't do that? Not their problem in the slightest, actually.
noah_buddy|2 years ago
sulam|2 years ago
amelius|2 years ago
ryanjshaw|2 years ago
kkajla|2 years ago
ants_everywhere|2 years ago
alxcb|2 years ago
seymon|2 years ago
kkajla|2 years ago
At Warrant, we're experimenting with allowing customers to maintain searchable metadata in Warrant and exposing a "query" API[1] that can automatically hydrate objects based on that metadata.
[1] https://docs.warrant.dev/warrants/query-warrants/
rektide|2 years ago
h1fra|2 years ago
When you access one resource it's fine to a do a roundtrip, but with listing, filtering, searching if you don't join at query time it doesn't work. I'm not entirely sure how they achieve it and I found it annoying that it's never mentioned because it's very common.
scarmig|2 years ago
How would you compare Warrant to other Zanzibar (ZaaS?) offerings? Particularly Ory and Authzed/SpiceDb.
zedadex|2 years ago
As a developer of a tiny internal webapp - this is fascinating to read! I like to keep things as simple as possible, but as with anything our scope and use cases have grown over time.
Our authzn can handle some of this stuff - our rules, built atop our org's existing IAM, are very similar to these directed relationship tuples - but as we need to grow that out any further I'm excited to look into which aspects of ReBaC we're still missing.
Thanks for the link!
AceJohnny2|2 years ago
They've posted a number of interesting articles on the topic here, such as this one listing competing implementations (but 2y old): https://authzed.com/blog/zanzibar-implementations
gneray|2 years ago
If so, how did you evaluate them relative to each other and/or building yourselves?
sails|2 years ago
Are there good examples of similar applications of data modules for similarly niche use cases? I get that there are obviously endless data models, but this seems to extend beyond that into a more integrated concept and I don’t quite know why that seems to be the case.
kkajla|2 years ago
deanCommie|2 years ago
joshuanapoli|2 years ago
So AWS groups do not nest, but Zanzibar groups do. In Zanzibar a relation on an object (an implicit set of users) can be the subject of a rule; you can define “users who have editor permission on an object also have viewer permission” in one rule. This isn’t possible in AWS; there is no way to reference the set of principals who are allowed a particular action or policy.
I think that AWS policies tend to have a lot of duplicate rules because of lacking recursion. Zanzibar rules should be easier to maintain and audit.
AWS IAM is also just quite “hairy” from gradual evolution over the years. On the other hand, Zanzibar has a clean model.
It would be nice to have a compiler that would emit AWS IAM Policies given Zanzibar-style rule tuples.
TheNewsIsHere|2 years ago
Zanzibar is a Google-internal implementation of the concepts outlined in this paper, focused on managing authorization as a function of relationships between objects.
AWS IAM is primarily for AAA services with AWS, though you can use it with AWS Identity Center to provide SSO to other systems via IAM.
say_it_as_it_is|2 years ago
Zanzibar is overkill for the majority of needs and introduces far too much complexity. It is the solution that covers scenarios of the likes in which you will never see. You will never grow into needing them, either. It is the pinnacle of over engineered software. The reason why people form companies offering it as a solution is to try to recover hundreds of hours of effort cost on something they didn't need.
esafak|2 years ago
fiddlerwoaroof|2 years ago
kkajla|2 years ago
kkajla|2 years ago
leetrout|2 years ago
https://authzed.com/blog/caveats
simongray|2 years ago
And the additional element added to the tuple is reminiscent of quads, also in heavy use in RDF implementations or similar graph databases.
unknown|2 years ago
[deleted]
rantingdemon|2 years ago
s09dfhks|2 years ago
[deleted]
kkajla|2 years ago
[1] https://github.com/warrant-dev/warrant
[2] https://warrant.dev
jsnell|2 years ago
ec109685|2 years ago
rzzzt|2 years ago
sowbug|2 years ago