As someone working on the most popular Zanzibar implementation[0], I think this article is a pretty good introduction to the idea that both policy engines and ReBAC databases have their use cases, but it doesn't offer great recommendations for what those use cases are. The article recommends policy engines where you'd want to apply global roles, but this is actually a commonly expressed pattern for schemas in SpiceDB and not something that requires a policy-forward approach.<p>I use the following as my "rule of thumb": ReBAC databases want to have deterministic computation for your permissions. In the default case, this should be your ideal as well as it is the most understandable/scalable/testable/auditable/debuggable. But reality is that there will be places where you'll want _some_ non-determinism and in those scenarios it makes sense to leverage policy engines.<p>The SpiceDB community is exploring what it might take to support adding lightweight policies to the Zanzibar-like model to have the best of both worlds. If that sounds interesting, you can participate in the proposal[1].<p>[0]: <a href="https://github.com/authzed/spicedb" rel="nofollow">https://github.com/authzed/spicedb</a><p>[1]: <a href="https://github.com/authzed/spicedb/issues/386" rel="nofollow">https://github.com/authzed/spicedb/issues/386</a>
This resonates to me. In my last job we didn't plan our authZ story very well (or at all!). As our company experienced explosive growth, we ended up implementing something that I suspect is pretty common: AuthZ policy as data because we ended up representing it in a postgres db, and policy as code because we then had to write an "engine" to interpret that data. There were none of these emerging cloud authZ solutions, having one might have saved us a lot of time and grief!
Disclaimer: I work on Cerbos [0] (an alternative to OPA based authorization systems focusing on RBAC/ABAC) to deliver enterprise-grade access management for any application.<p>There is another alternative approach to policy-as-code: policy-as-configuration. At Cerbos we believe that for most use cases, using a full programming language is too much work and creates problems such as being hard to comprehend and work with (because it's a completely different language with its own idiosyncrasies) and being too open-ended (thus making it easy to write lots of very complicated code with surprising side effects and performance issues). The rules for your authorization policies can be human readable for those developers who cannot spend lots of time learning a whole new programming language, and is independent of any particular language, architecture or tech stack.<p>We’ve built and open sourced Cerbos trying to make the deployment and management of an authorization service as simple as possible while configuration rules as flexible as possible. While doing so, we also achieved response times that are faster than OPA.<p>[0] <a href="https://cerbos.dev" rel="nofollow">https://cerbos.dev</a>
In the "Zanzibar [0] vs OPA [1]" debate, the pragmatic answer is "both".<p>[0] <a href="https://research.google/pubs/pub48190/" rel="nofollow">https://research.google/pubs/pub48190/</a><p>[1] <a href="https://www.openpolicyagent.org/" rel="nofollow">https://www.openpolicyagent.org/</a>