Is that a Metal Gear Solid[1] reference? [1]: https://metalgear.fandom.com/wiki/Zanzibar_Land_Disturbance
One of the project authors (Lea Kissner) relates the story to the naming of the project here:
Zanzibar: Google’s Consistent, Global Authorization System (2019)
41–50 of 99 posts
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#42Here's a decent twitter thread (2019) with some background on the project:
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#43I'm currently building an abstracted authorization system for PostgreSQL, and one problem I ran into were timing attacks. Granted, I only had an unoptimised prototype, but querying a table and only checking if the user has permission to read the objects after the fact led to being able to differentiate "no matching object" and "one unavailable matching object". From skimming the paper, it seems Google use this approach, why are timing attacks not a problem for them? Is it because authorization checks are so fast? Or because they make sure only to query available objects, only using Zanzibar as a final "just in case" guard?
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#44I'm currently building an abstracted authorization system for PostgreSQL, and one problem I ran into were timing attacks. Granted, I only had an unoptimised prototype, but querying a table and only checking if the user has permission to read the objects after the fact led to being able to differentiate "no matching object" and "one unavailable matching object". From skimming the paper, it seems Google use this approa…
Maybe evening response time is some abstraction on top? It may be useful for protecting much more than just auth so it would make sense not to repeat that on every layer.
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#45Is that a Metal Gear Solid[1] reference? [1]: https://metalgear.fandom.com/wiki/Zanzibar_Land_Disturbance
One of the project authors (Lea Kissner) relates the story to the naming of the project here: https://twitter.com/LeaKissner/status/1136691523104280576
Well, that was unexpected. I would have gone with Stand on Zanzibar as the other poster mentioned. Also makes me feel old that they don't remember the spice channel...
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#46Maybe a dumb question on standalone authorization services: does the authorization service end up having a representation for every single object in all of the rest of your datastores? (e.g. every document, every blob of storage, every user in every org). If so, does that become a chokepoint in a distributed microservice architecture? Or can that be avoided with an in-process or sidecar architecture in which a given…
I've been writing about application authorization here: https://www.osohq.com/academy/chapter-2-architecture (I'm CTO at Oso, but these guides are not Oso specific). It covers this in the later part of the guide.
Depending on your requirements, yes that's kind of what happens if you want to centralise. It can make sense for Google-scale problems where you really do need to handle the complex graph of relationships between all users and resources, and doing that in any one service is non-trivial.
In practice though, a lot of service-oriented architectures can get the same benefits by having a central user management service, and keeping most of the authorization in each service. That central service can provide information like what organizations/teams/roles etc. the user belongs to, and then the individual services can make decisions based on that data.
This is the approach I covered with the hybrid approach. With this you can still implement most complex authorization models.
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#47I can't get over the name because I definitely had a memorable experience going to Zanzibar in Toronto (https://www.yelp.ca/biz/zanzibar-toronto) shortly after turning 19.
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#48Earlier quoted context omitted.
Airbnb Himeji also: https://medium.com/airbnb-engineering/himeji-a-scalable-cent...
Casbin is another that’s pretty interesting I’ve been evaluating alongside Ory’s https://casbin.org/
Is it my impression or nowadays the emerging technology in this sense is OPA (Open Policy Agent)?
It looks like a flexible system to build cross-language and cross-framework authorization systems.
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#49I'm currently building an abstracted authorization system for PostgreSQL, and one problem I ran into were timing attacks. Granted, I only had an unoptimised prototype, but querying a table and only checking if the user has permission to read the objects after the fact led to being able to differentiate "no matching object" and "one unavailable matching object". From skimming the paper, it seems Google use this approa…
Maybe evening response time is some abstraction on top? It may be useful for protecting much more than just auth so it would make sense not to repeat that on every layer.
I considered that, but it seems way too fragile to trust, expecially if you want to test complex relationships for authorization.
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#50Maybe a dumb question on standalone authorization services: does the authorization service end up having a representation for every single object in all of the rest of your datastores? (e.g. every document, every blob of storage, every user in every org). If so, does that become a chokepoint in a distributed microservice architecture? Or can that be avoided with an in-process or sidecar architecture in which a given…
A Zanzibar-style service does not need _every_ object from your DB replicated into it, but only the relationships between the objects that matter for authorizing access. Many of these relationships require little/no metadata in your DB so they can live _solely_ in Zanzibar rather than being in both your DB and Zanzibar. This is pretty great because when permissions requirements change, you can often address them by only changing the Zanzibar schema, completely avoiding a database migration.
>does that become a chokepoint in a distributed microservice architecture?
It actually does the opposite because now all of your microservices can query Zanzibar at any time to get answers to authorization questions that were previously isolated to only a single application.
Full disclosure: I work on https://authzed.com (YC W21) -- a permission system as a service inspired by Zanzibar. We're also planning on doing a PapersWeLove NYC on Zanzibar in the coming months, so stay tuned!