[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]
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.
Bundle servers provide a centralized "data plane" decoupled from the distributed component (OPA). You don't need to rebuild your policy any time data changes. Just push a new bundle with the data that changed, and OPA will fetch it as configured — either periodically or directly if long polling is configured.
This feels very much like OpenFGA[0]. I've been evaluating authorization tool for one of my side projects and honestly most tools feels like creating relationships in a graph-like database and querying to see if there is/isn't relationship between two entities. Is there more to this (besides the implementation details) or am I missing something from these tools?
On the first point, OPA is much older than OpenFGA. To really illustrate the point, OPA became a graduated project about a year before OpenFGA had their first code drop in the public GitHub repo. The OpenFGA people are aware of OPA and I'm sure they learned from the tradeoffs OPA made.
To the main point, what you described reflects the current trends of authorization. Define a data model, define data that adheres to that model, write declarative rules that consume that model, make a decision based on those rules.
Where things really start to differ is the kind of data that they bind against and how do you write rules. E.g. OPA is often used for either ABAC (Attribute) or RBAC (Roles) while OpenFGA is looking at ReBAC (Relationships). Each has their complexity tradeoffs, depending on the system being implemented. How easy or difficult a system makes these kinds of checks has a significant impact on how you write policies.
Yeah, that's what I've noticed too. Conceptually, they're more or less same giving an option of RBAC, ABAC or ReBAC and each offer their own DSLs (e.g. Oso, Ory Keto etc) and deployment strategies. It's been a bit harder to pick one honestly but I guess I'll just have to just use them to find which one fits for me.
Not sure why that matters, but OpenFGA is an implementation of Zanzibar, which isn't exactly new. There are many similar implementations to choose from should one want to model authorization via a graph database.
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.
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.
[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...