ogazitt
Joined 14 years ago
Karma
185
Submissions
102
Member since
Aug 23
co-founder aserto.com
https://github.com/ogazitt
https://twitter.com/omrig
View on Hacker NewsRecent submissions
Comment · 2 years ago
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...
Comment · 2 years ago
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 :)
Comment · 2 years ago
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.
Comment · 2 years ago
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.
[1] https://research.google/pubs/zanzibar-googles-consistent-glo...
Comment · 2 years ago
LetsGo looks really cool! Excited to see how this evolves.
Comment · 3 years ago
Really cool to see an identity provider that's free, both in price and in friction. Nicely done!
Comment · 3 years ago
Thanks! Yes, the days where you have to hand-roll authorization logic are (hopefully) soon to be behind us :)
Comment · 3 years ago
Thanks! That's exactly the analogy we think of... Auth0 : AuthN :: Topaz : AuthZ :)
Comment · 3 years ago
Thanks! Do let us know what your favorite feature is in the 0.30 release :)
Comment · 3 years ago
Thanks! ABAC and ReBAC are indeed complementary, and you can build powerful authorization models by combining the best of these.
Comment · 3 years ago
Thanks! "topaz test" is already pretty useful, and we hope to bring assertions into the visual console in a future release.
Comment · 3 years ago
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.