Combining policy with Zanzibar is super cool and it's great to see the folks in the OPA ecosystem moving in this direction. Most of the novelty of the Zanzibar paper is about scaling ReBAC systems that might not be applicable in a system that starts with policy. Unfortunately, I found the website a little vague on technical details and had some questions:
- I'm curious how this is different from using an API client in rego, which other projects like OpenFGA and SpiceDB support.
- It seems like for the variety of projects in this space "Zanzibar" is used to mean many different things mentioned in the paper. Can you clarify which properties Topaz is inspired by? From the documentation, I can only find references to tuples and union rewrites[0].
Disclosure: I work on SpiceDB, an established open source project also "inspired by Zanzibar" that also has policy integrations with OPA and Google's CEL.
[0]: https://www.topaz.sh/docs/directory/define-domain-model
We provide a set of OPA built-ins which enable the integration which are documented here: https://www.topaz.sh/docs/directory/built-ins.
Since there is a clear interest from the existing communities with mature solutions, it'd be awesome to collaborate for the graph layer. Speaking from the SpiceDB community, we'd be glad to welcome you -- this is what open source is all about!
[0]: https://github.com/thomasdarimont/custom-opa-openfga
Wonder if there are planned integrations with any stacks? For instance, would be super cool to see how this could plug into Rails/ActiveRecord for a kind of out-of-the-box authorization experience.
[0] https://ory.sh
Ory Keto's intro video @ SV IAM User Group [0] is worth a watch.
Other OSS Zanzibar implementations:
- https://github.com/authzed/spicedb
- https://github.com/Permify/permify
- https://github.com/openfga/openfga
[0]: https://www.youtube.com/watch?v=3vtTFLB_jDo
[Disclaimer: On the OpenFGA team]
It’s like all these ostensibly OS libraries deliberately make it hard to set up to drive you to their paid offering.
[1] https://www.topaz.sh/docs/software-development-kits/ruby/mid...
[2] https://www.topaz.sh/docs/software-development-kits/ruby/rai...
We were working in Healthcare and the authorization requirements for healthcare are quite complicated. Every Microservice needed to handle 50 different roles and get the permissions right for each endpoint, so a more centralised approach made a lot of sense to prevent these types of mistakes
Cool to see an open source implementation of the idea. Authorization in general is such a hard topic to get right in a microservice architecture. I'd be happy to take a look at the project and see if I can contribute as well!
Many people appreciate the middleware approach as it provides coverage for the API surface with minimal investment, so a great way to get started.
But there is no free lunch
Google [1], Airbnb [2], Netflix [3], Carta [4], Intuit [5], and others have written about their authorization systems. It's clear that these are all significant undertakings by sizable teams. Most engineering organizations don't want to spend their precious cycles reinventing this wheel.
Over the last two years, we've collected a set of best practices that are common across these projects. We call these the Principles of Authorization [6]. Our goal has been to democratize these principles into an authorization service, and save you time and effort.
Topaz [7] is an open source authorization system you can use to start building robust authorization in minutes. It provides fine-grained, real-time, policy-based access control for modern cloud applications. You can deploy it as a sidecar or a microservice in your cloud, ensuring low latency to your application.
Topaz combines the best ideas from two cloud-native authorization ecosystems: OPA and Zanzibar. Read our blog post [8] for more on why we built Topaz.
Happy hacking!
[1] https://research.google/pubs/pub48190/
[2] https://medium.com/airbnb-engineering/himeji-a-scalable-cent...
[3] https://www.infoq.com/presentations/authorization-scalabilit...
[4] https://medium.com/building-carta/authz-cartas-highly-scalab...
[5] https://medium.com/intuit-engineering/authz-intuits-unified-...
[6] https://www.topaz.sh/docs/intro#principles
[7] https://github.com/aserto-dev/topaz
[8] https://www.aserto.com/blog/topaz-oss-cloud-native-authoriza...
We do have a gRPC contract for the directory (which is pluggable in Topaz), and it would be interesting to see if there could be SpiceDB or OpenFGA implementations of that contract!
FWIW I totally see the benefit of having standards and widely adopted open source solutions, Jimmy. But neither of the solutions you called out has been out for more than ~1 year, so I can also see why Omri and the Topaz team decided to go their own route. Your two companies also compete directly with each other, so I can’t really blame them.
Neither of those solutions was around when we released the first version of Oso in 2020, so we too went our own route and have learned a lot along the way. We’ve since shared a lot of what we’ve learned in Authorization Academy [0], a series of technical guides on building application authorization that are not specific to Oso. We also recently wrote about our view of what an authorization system should look like — opinionated but flexible — in a post on what authorization can learn from Rails [1].
Will be instructive to see what feedback the dev community shares in the years to come.
Disclaimer: I'm founder of Oso[2], a batteries-included system for authorization.
[0] https://www.osohq.com/academy
[1] https://www.osohq.com/post/learn-authorization-from-rails
That's a good callout. These are still early days when it comes to Zanzibar & co, and all implementations are very new. I'm glad different implementations exist. This will allow the community to experiment with multiple ideas and allow them to flourish or be discarded.
Authzed's idea Jimmy linked to elsewhere (Caveats) [0] is not in the Zanzibar paper, however it is an interesting option to try to tackle ABAC scenarios within a Zanzibar context.
OSO (and Aserto seems to be doing the same) is approaching this the other way - they have a good Policy/ABAC solution, do they benefit from a more Zanzibar-like approach to the AuthZ problem, the answer seems to be also yes (OSO Cloud [1]).
In OpenFGA, we dropped the concept of Zookies. Will we regret this? Time will tell. SpiceDB bet on the importance of Zookies, and in some cases they are right. We also added support for having multiple model versions active at the same time and some ABAC scenarios through Contextual Tuples [2] (less powerful than caveats, but more Zanzibar-y). Is that a good idea? Hopefully!
That's the beauty of it, there are considerations (pros and cons) for all of these approaches, users can pick and choose what works best for their situations. We will all learn and adapt. We may all end up discarding some of our assumptions and adopting new ones. Ultimately this will benefit all of us, and more importantly the wider audience and the ecosystem. And maybe newcomers will implement all of the good ideas floating around while discarding the cruft existing solutions are stuck with.
Hopefully as the ecosystem matures, all the implementations benefit from it. Multiple implementations allows each to investigate certain solutions.
Quoting Jimmy above:
> it'd be awesome to collaborate [...] this is what open source is all about
100%! Though as a FOSS fan myself, I'm hoping for a new comer GPL/copyleft solution to come about and rule us all :)
Side-note: Absolutely loved this article from OSO with Abhishek Parmar, one of the co-creators of Zanzibar [3]
[0]: https://github.com/authzed/spicedb/issues/386
[1]: https://www.osohq.com/docs/concepts/oso-cloud-data-model
[2]: https://openfga.dev/docs/modeling/contextual-time-based-auth...
[3]: https://www.osohq.com/post/abhishek-parmar-oso
[Disclaimer: On the OpenFGA team]
Having the authorizer integrate based on contract feels like an option which allows for more freedom of choice and variety of implementations.
I do not believe in one size fits all, nor that there is one to rule them all.
You're exactly right that with Aserto (and Topaz), we started from a Policy-as-code design at the center. As we spent time with developers, we recognized that having a way to model their domain and write data-centric rules (ReBAC tuples) was a powerful extension to the policy-as-code approach. Bringing them together is the focus of Topaz.
Thanks for posting the link to the interview with Abhishek - great read!