ogazitt

Congrats on the launch!

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

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

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.

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

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

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

LetsGo looks really cool! Excited to see how this evolves.

Really cool to see an identity provider that's free, both in price and in friction. Nicely done!

Thanks! Yes, the days where you have to hand-roll authorization logic are (hopefully) soon to be behind us :)

Thanks! That's exactly the analogy we think of... Auth0 : AuthN :: Topaz : AuthZ :)

Thanks! Do let us know what your favorite feature is in the 0.30 release :)

Thanks! ABAC and ReBAC are indeed complementary, and you can build powerful authorization models by combining the best of these.

Thanks! "topaz test" is already pretty useful, and we hope to bring assertions into the visual console in a future release.

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! Let us know if you have any feedback!

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 :)

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

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

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 :)

Would love any feedback you have on setting up Topaz, if you choose to give it a try! We built it to be useful completely standalone.

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!

Thanks! :)

Thanks! We do have Rack middleware [1], as well as a Rails integration [2]. Let us know what you think!

[1] https://www.topaz.sh/docs/software-development-kits/ruby/mid...

[2] https://www.topaz.sh/docs/software-development-kits/ruby/rai...

Two years ago, we founded Aserto to simplify authorization for developers. Authorization is critical and hard to get right, yet isn't a source of differentiation for most applications.

Google [1], Airbnb [2], Netflix [3], Carta [4], Intuit [5], and others have written about their authorization systems. It's clear that these are all significant undertakings by sizable teams. Most engineering organizations don't want to spend their precious cycles reinventing this wheel.

Over the last two years, we've collected a set of best practices that are common across these projects. We call these the Principles of Authorization [6]. Our goal has been to democratize these principles into an authorization service, and save you time and effort.

Topaz [7] is an open source authorization system you can use to start building robust authorization in minutes. It provides fine-grained, real-time, policy-based access control for modern cloud applications. You can deploy it as a sidecar or a microservice in your cloud, ensuring low latency to your application.

Topaz combines the best ideas from two cloud-native authorization ecosystems: OPA and Zanzibar. Read our blog post [8] for more on why we built Topaz.

Happy hacking!

[1] https://research.google/pubs/pub48190/

[2] https://medium.com/airbnb-engineering/himeji-a-scalable-cent...

[3] https://www.infoq.com/presentations/authorization-scalabilit...

[4] https://medium.com/building-carta/authz-cartas-highly-scalab...

[5] https://medium.com/intuit-engineering/authz-intuits-unified-...

[6] https://www.topaz.sh/docs/intro#principles

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

[8] https://www.aserto.com/blog/topaz-oss-cloud-native-authoriza...

That is super cool! Really curious to hear how it's built, how much runs in wasm, how you got (some portions of) postgres to compile to wasm, etc.

Auto-scaling for ML workloads, integrated with the TF workflow - very cool!

The playground is cool. The time-travel component is really neat!

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

Did you represent user -> role mappings in your postgres db, or did you model ACLs for every object?

In the "Zanzibar [0] vs OPA [1]" debate, the pragmatic answer is "both".

[0] https://research.google/pubs/pub48190/

[1] https://www.openpolicyagent.org/

We have based our entire deployment pipeline on GHA. Works great when it works... and after all the outages of the past month, we're working on an exit strategy.