[HN Gopher] Show HN: Topaz: open-source authorization combining ...
___________________________________________________________________
Show HN: Topaz: open-source authorization combining the best of OPA
and Zanzibar
Author : ogazitt
Score : 94 points
Date : 2022-10-24 15:01 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| renszarv wrote:
| Yet another golang gRPC authorization framework... That couple of
| ms response time for a decision could be fine,if you only call a
| couple of time per request,but its quickly adds up
| gertd wrote:
| Which is exactly why using a middleware is an option and
| therefore a decision the implementor makes.
|
| Many people appreciate the middleware approach as it provides
| coverage for the API surface with minimal investment, so a
| great way to get started.
|
| But there is no free lunch
| jzelinskie wrote:
| Congrats on the launch!
|
| Combining policy with Zanzibar is super cool and it's great to
| see the folks in the OPA ecosystem moving in this direction. Most
| of the novelty of the Zanzibar paper is about scaling ReBAC
| systems that might not be applicable in a system that starts with
| policy. Unfortunately, I found the website a little vague on
| technical details and had some questions:
|
| - I'm curious how this is different from using an API client in
| rego, which other projects like OpenFGA and SpiceDB support.
|
| - It seems like for the variety of projects in this space
| "Zanzibar" is used to mean many different things mentioned in the
| paper. Can you clarify which properties Topaz is inspired by?
| From the documentation, I can only find references to tuples and
| union rewrites[0].
|
| Disclosure: I work on SpiceDB, an established open source project
| also "inspired by Zanzibar" that also has policy integrations
| with OPA and Google's CEL.
|
| [0]: https://www.topaz.sh/docs/directory/define-domain-model
| gertd wrote:
| When it comes to integration of external capabilities in OPA
| there are only two options: make a REST call, or add a built-
| in.
|
| We provide a set of OPA built-ins which enable the integration
| which are documented here:
| https://www.topaz.sh/docs/directory/built-ins.
| jzelinskie wrote:
| Both REST and built-ins for OPA have been available for
| existing projects like OpenFGA[0] and SpiceDB[1]. In case of
| SpiceDB, the first built-in was actually available in June of
| last year[2].
|
| Since there is a clear interest from the existing communities
| with mature solutions, it'd be awesome to collaborate for the
| graph layer. Speaking from the SpiceDB community, we'd be
| glad to welcome you -- this is what open source is all about!
|
| [0]: https://github.com/thomasdarimont/custom-opa-openfga
|
| [1]: https://github.com/thomasdarimont/custom-opa-spicedb
|
| [2]: https://github.com/authzed/zed/pull/5
| ogazitt wrote:
| 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!
| jzelinskie wrote:
| Both OpenFGA and SpiceDB are also implemented in Go, so
| they could also easily be included as a library. SpiceDB
| can even be compiled to WASM!
| gertd wrote:
| Not having to tied them together into a single process
| space is an interesting option/ability which would get
| lost with using it as a library.
|
| Having the authorizer integrate based on contract feels
| like an option which allows for more freedom of choice
| and variety of implementations.
|
| I do not believe in one size fits all, nor that there is
| one to rule them all.
| gneray wrote:
| Hey, congrats on the launch! It's great to see more
| activity in the authorization domain - a rising tide
| floats all boats.
|
| FWIW I totally see the benefit of having standards and
| widely adopted open source solutions, Jimmy. But neither
| of the solutions you called out has been out for more
| than ~1 year, so I can also see why Omri and the Topaz
| team decided to go their own route. Your two companies
| also compete directly with each other, so I can't really
| blame them.
|
| Neither of those solutions was around when we released
| the first version of Oso in 2020, so we too went our own
| route and have learned a lot along the way. We've since
| shared a lot of what we've learned in Authorization
| Academy [0], a series of technical guides on building
| application authorization that are not specific to Oso.
| We also recently wrote about our view of what an
| authorization system _should look like_ -- opinionated
| but flexible -- in a post on what authorization can learn
| from Rails [1].
|
| Will be instructive to see what feedback the dev
| community shares in the years to come.
|
| Disclaimer: I'm founder of Oso[2], a batteries-included
| system for authorization.
|
| [0] https://www.osohq.com/academy
|
| [1] https://www.osohq.com/post/learn-authorization-from-
| rails
|
| [2] https://www.osohq.com/
| rhamzeh wrote:
| > neither of the solutions you called out has been out
| for more than ~1 year,
|
| That's a good callout. These are still early days when it
| comes to Zanzibar & co, and all implementations are very
| new. I'm glad different implementations exist. This will
| allow the community to experiment with multiple ideas and
| allow them to flourish or be discarded.
|
| Authzed's idea Jimmy linked to elsewhere (Caveats) [0] is
| not in the Zanzibar paper, however it is an interesting
| option to try to tackle ABAC scenarios within a Zanzibar
| context.
|
| OSO (and Aserto seems to be doing the same) is
| approaching this the other way - they have a good
| Policy/ABAC solution, do they benefit from a more
| Zanzibar-like approach to the AuthZ problem, the answer
| seems to be also yes (OSO Cloud [1]).
|
| In OpenFGA, we dropped the concept of Zookies. Will we
| regret this? Time will tell. SpiceDB bet on the
| importance of Zookies, and in some cases they are right.
| We also added support for having multiple model versions
| active at the same time and some ABAC scenarios through
| Contextual Tuples [2] (less powerful than caveats, but
| more Zanzibar-y). Is that a good idea? Hopefully!
|
| That's the beauty of it, there are considerations (pros
| and cons) for all of these approaches, users can pick and
| choose what works best for their situations. We will all
| learn and adapt. We may all end up discarding some of our
| assumptions and adopting new ones. Ultimately this will
| benefit all of us, and more importantly the wider
| audience and the ecosystem. And maybe newcomers will
| implement all of the good ideas floating around while
| discarding the cruft existing solutions are stuck with.
|
| Hopefully as the ecosystem matures, all the
| implementations benefit from it. Multiple implementations
| allows each to investigate certain solutions.
|
| Quoting Jimmy above:
|
| > it'd be awesome to collaborate [...] this is what open
| source is all about
|
| 100%! Though as a FOSS fan myself, I'm hoping for a new
| comer GPL/copyleft solution to come about and rule us all
| :)
|
| Side-note: Absolutely loved this article from OSO with
| Abhishek Parmar, one of the co-creators of Zanzibar [3]
|
| [0]: https://github.com/authzed/spicedb/issues/386
|
| [1]: https://www.osohq.com/docs/concepts/oso-cloud-data-
| model
|
| [2]: https://openfga.dev/docs/modeling/contextual-time-
| based-auth...
|
| [3]: https://www.osohq.com/post/abhishek-parmar-oso
|
| [Disclaimer: On the OpenFGA team]
| ogazitt wrote:
| 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!
| apoland wrote:
| Great work Aserto team. Exciting to see this code released to the
| community.
| ogazitt wrote:
| Thanks! :)
| fleddr wrote:
| You may have some SEO problems with a name like that. Topaz is a
| very popular suite of (AI-driven) photo editing tools.
| ogazitt wrote:
| 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...
| bradhe wrote:
| Ah, super cool to see an implementation of Zanzibar out in the
| wild. The paper looked really interesting when it bubbled up on
| HN a while back.
|
| Wonder if there are planned integrations with any stacks? For
| instance, would be super cool to see how this could plug into
| Rails/ActiveRecord for a kind of out-of-the-box authorization
| experience.
| robertlagrant wrote:
| Ory [0] is also an OSS Zanzibar implementation.
|
| [0] https://ory.sh
| rschwabco wrote:
| That's cool! What's neat about Topaz is that it combines the
| Zanzibar approach and the policy-as-code approach. That
| allows you to use the ReBAC, ABAC and RBAC authz patterns
| interchangeably.
| Aeolun wrote:
| Trying to set up Ory was really hard though.
|
| It's like all these ostensibly OS libraries deliberately make
| it hard to set up to drive you to their paid offering.
| rhamzeh wrote:
| Love the growing number of OSS Zanzibar implementations, and
| congrats to the Aserto team for launching Topaz!
|
| Ory Keto's intro video @ SV IAM User Group [0] is worth a
| watch.
|
| Other OSS Zanzibar implementations:
|
| - https://github.com/authzed/spicedb
|
| - https://github.com/Permify/permify
|
| - https://github.com/openfga/openfga
|
| [0]: https://www.youtube.com/watch?v=3vtTFLB_jDo
|
| [Disclaimer: On the OpenFGA team]
| ogazitt wrote:
| 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...
| [deleted]
___________________________________________________________________
(page generated 2022-10-24 23:01 UTC)