4 ms·

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

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 https://www.topaz.sh/docs/directory/define-domain-model

gertd 4y ago
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 https://www.topaz.sh/docs/directory/built-ins.
- jzelinskie 4y ago
  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 https://github.com/thomasdarimont/custom-opa-openfga [1]: https://github.com/thomasdarimont/custom-opa-spicedb https://github.com/thomasdarimont/custom-opa-spicedb [2]: https://github.com/authzed/zed/pull/5 https://github.com/authzed/zed/pull/5
  - ogazitt 4y ago
    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 4y ago
      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 4y ago
        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 4y ago
      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 https://www.osohq.com/academy [1] https://www.osohq.com/post/learn-authorization-from-rails https://www.osohq.com/post/learn-authorization-from-rails [2] https://www.osohq.com/ https://www.osohq.com/

gertd 4y ago

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 https://www.topaz.sh/docs/directory/built-ins.

jzelinskie 4y ago
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 https://github.com/thomasdarimont/custom-opa-openfga [1]: https://github.com/thomasdarimont/custom-opa-spicedb https://github.com/thomasdarimont/custom-opa-spicedb [2]: https://github.com/authzed/zed/pull/5 https://github.com/authzed/zed/pull/5
- ogazitt 4y ago
  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 4y ago
    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 4y ago
      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 4y ago
    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 https://www.osohq.com/academy [1] https://www.osohq.com/post/learn-authorization-from-rails https://www.osohq.com/post/learn-authorization-from-rails [2] https://www.osohq.com/ https://www.osohq.com/