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.<p>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.<p>[0]: <a href="https://www.ory.sh/keto/" rel="nofollow noreferrer">https://www.ory.sh/keto/</a>
[1]: <a href="https://auth0.com/developers/lab/fine-grained-authorization" rel="nofollow noreferrer">https://auth0.com/developers/lab/fine-grained-authorization</a>
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”).<p>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.<p>Good luck with your startup!<p>[0]: <a href="https://www.w3.org/TR/rdf11-primer/" rel="nofollow noreferrer">https://www.w3.org/TR/rdf11-primer/</a><p>[1]: <a href="https://github.com/warrant-dev/warrant/tree/main/pkg/authz/object">https://github.com/warrant-dev/warrant/tree/main/pkg/authz/o...</a>
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).<p>How does Warrant deal with consistency?
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.
It's exciting to see so much action in this space.<p>How would you compare Warrant to other Zanzibar (ZaaS?) offerings? Particularly Ory and Authzed/SpiceDb.
> 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<p>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.<p>Our authzn can handle some of this stuff - our rules, built atop our org's existing IAM, are <i>very</i> 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.<p>Thanks for the link!
Plugging another company that's been implementing Google-Zanzibar-like auth tech: <a href="https://authzed.com/">https://authzed.com/</a><p>They've posted a number of interesting articles on the topic here, such as this one listing competing implementations (but 2y old): <a href="https://authzed.com/blog/zanzibar-implementations">https://authzed.com/blog/zanzibar-implementations</a>
Is anyone here using Warrant or other Zanzibar-like services?<p>If so, how did you evaluate them relative to each other and/or building yourselves?
> A Flexible, Uniform Data Model for Authorization<p>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.
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.<p>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.
Add this to the list of blog posts praising RDF without anyone realising it.<p>And the additional element added to the tuple is reminiscent of quads, also in heavy use in RDF implementations or similar graph databases.