[Disclosure: I'm one of the co-founders of Aserto, the creators of Topaz].
The problem of data filtering is indeed a huge part of building an effective authorization system. Partial evaluation is one way of doing it, although with systems like OPA [0] it requires a lot of heavy lifting (parsing the returned AST and converting it into a WHERE clause). Looking forward to seeing how turnkey that can be with Oso.
With that said, there are applications where you really want the data close to the authorization engine. With a ReBAC model, you can easily find the objects that a user has access to, or the users that have access to an object, by walking the relationship graph. That's the approach we've taken with Topaz [1].
Funny timing - a few days ago we published a blog post on that very topic! [2]
Topaz is essentially a combination of OPA (which is used as the decision engine, with full support for Rego), and a Zanzibar-style directory, which is fairly isomorphic to what OpenFGA has implemented.
The advantage is that it's a single container image (or go binary, if that's how you want to run it), and supports a combination of RBAC, ABAC, and ReBAC. ABAC is accomplished via the Rego language, which is as "standard" as it comes in the cloud-native world.
OPA is a great tool for implementing a policy-as-code system. But if you're trying to use it for application authorization (e.g. fine-grained authz for B2B SaaS or a set of internal applications), you may find that its policy story is strong, but it doesn't really have a "data plane": you either store data in a data.json file and rebuild the policy any time that data changes, or make an http.send call out of the policy to fetch dynamic data.
Check out Topaz [0], which uses OPA as its decision engine, but adds a data plane that is based on the ReBAC ideas explored in the Google Zanzibar [1] paper.
Disclaimer: I work on the team [2] that builds and maintains the Topaz project.
Thanks for the question! Those are both great projects. Topaz combines the best elements of both:
* It uses OPA as its decision engine and Rego as the policy language, and supports the "policy as code" methodology
* It also implements a ReBAC directory, much like OpenFGA, in the same container image. It goes further, by allowing you to store not just relationships between subjects and objects, but also properties... which makes it easy to author policies that combine attribute-based (ABAC) and relationship-based (ReBAC) rules.
Thanks! Analogies are always challenging, but the Zanzibar ReBAC model fits the “opinion” and “simplicity” of REST (at least when compared to SOAP).
We will definitely need the “Rails” equivalent for making ReBAC accessible to many more developers than it is today, and Topaz / Aserto definitely aims to be one of these! :)
Good question. OPA is best suited for ABAC-centric scenarios, where your authorization logic is expressed in terms of attributes on users, objects, or environment.
The ReBAC / Zanzibar model is more opinionated, but most use-cases seem to be pretty easily described in ReBAC.
Thanks! Would love to exchange ideas. Please feel free to join our community slack [0] or open an issue on the GitHub tracker [1]. We also accept PR's :)
Really great context on what worked and what was perhaps overengineered. The approachability of any system by its consumers (developers in this case) is hugely important. You've done a good job with Oso :)
I'm Omri, one of the Aserto co-founders. Very much agree that this space is still pretty early - we all started building developer-centric authorization solutions in the last couple of years, and we're still in the phase where exploring different trade-offs helps the overall ecosystem learn and move forward.
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!
Our design approach with Aserto has been to have a single OPA-based decision engine integrated with a built-in directory. So Topaz carries this forward.
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!
[Disclosure: I'm one of the co-founders of Aserto, the creators of Topaz].
The problem of data filtering is indeed a huge part of building an effective authorization system. Partial evaluation is one way of doing it, although with systems like OPA [0] it requires a lot of heavy lifting (parsing the returned AST and converting it into a WHERE clause). Looking forward to seeing how turnkey that can be with Oso.
With that said, there are applications where you really want the data close to the authorization engine. With a ReBAC model, you can easily find the objects that a user has access to, or the users that have access to an object, by walking the relationship graph. That's the approach we've taken with Topaz [1].
Funny timing - a few days ago we published a blog post on that very topic! [2]
[0] https://openpolicyagent.org
[1] https://topaz.sh
[2] https://www.aserto.com/blog/how-rebac-helps-solve-data-filte...