[ogazitt]

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.

[0] https://www.topaz.sh

[1] https://research.google/pubs/zanzibar-googles-consistent-glo...

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

[andyroid]

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.

https://www.openpolicyagent.org/docs/latest/management-bundl...

[shriek]

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?

[0] https://openfga.dev/

[ffk]

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.

Hope this helps!

[shriek]

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.

[ogazitt]

If you want to try Topaz (which supports all three), check it out here [0]. We'd love to help you solve your authorization scenario :)

[0] https://github.com/aserto-dev/topaz

[andyroid]

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.

[ogazitt]

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.

[esafak]

You're describing ReBAC, which is the paradigm popularized by Google's Zanzibar. There are alternatives like RBAC, and ABAC.