Hacker News new | ask | show | jobs
by jzelinskie 1539 days ago
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.

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].

[0]: https://github.com/authzed/spicedb

[1]: https://github.com/authzed/spicedb/issues/386
1 comments
ogazitt 1539 days ago
Disclaimer: I work on Aserto [0] (one of those new dev authorization systems).

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)

[0] https://www.aserto.com

link