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.
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].
First, it seems like we both agree that having the flexibility to extend a base model is a good thing, whether that base model is OPA or Zanzibar.
I wouldn't call the ABAC scenarios "non-deterministic" - for the same inputs, it should produce the exact same outputs. But those inputs may include data that is sourced from the environment the user is in (e.g. date/time, location/IP address, etc).
Where model you start with is probably up for debate. To me, ReBAC starts making sense when there is a resource context to evaluate. There are plenty of customer scenarios we've encountered where modeling permissions for operations is sufficient, and doesn't require a resource context (or the resource context is very lightweight - e.g. "tenant", "project", "team", "organization", "list", etc)
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.
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.
