Maybe 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).<p>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 microservice's objects are not separately referenced in auth persistence? If not, how do folks determine which objects to register with the auth service and which to handle independently?
This was talked about 2 years ago on here[0]. This service was also brought up in the discussion[1] of Ory Keto, as it's based on Zanzibar.<p>[0] <a href="https://news.ycombinator.com/item?id=20132520" rel="nofollow">https://news.ycombinator.com/item?id=20132520</a><p>[1] <a href="https://news.ycombinator.com/item?id=26738344" rel="nofollow">https://news.ycombinator.com/item?id=26738344</a>
There is an Open Source (Go) implementation of "Zanzibar" called
Keto [0] that integrates with the rest of the Ory ecosystem. We are actually testing it and looks great so far.<p>[0]: <a href="https://github.com/ory/keto" rel="nofollow">https://github.com/ory/keto</a>
I'm curious what's driving the resurgence in interest authorization infrastructure, particularly the Zanzibar paper. As founder of Oso (<a href="https://www.osohq.com/" rel="nofollow">https://www.osohq.com/</a>), I have my own opinions, and I think this is a good thing. But would love to hear others' points of view here.
Here's a decent twitter thread (2019) with some background on the project:<p><a href="https://twitter.com/LeaKissner/status/1136631437514272768" rel="nofollow">https://twitter.com/LeaKissner/status/1136631437514272768</a>
I'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?
One of the authors is Mike Burrows -- <a href="https://en.m.wikipedia.org/wiki/Michael_Burrows" rel="nofollow">https://en.m.wikipedia.org/wiki/Michael_Burrows</a>
I'm just wondering if there's a one size fits all solution for authz. I spent a few days on a use case :
- users have one or several roles ( these are hierarchical )
- there are some objects in the system ( hierarchical too, eg files and folders )
- there are different features available according to a user's subscription.
I ended up with a 30 lines program which given a set of rules calculates who can access what in less than a millisecond. Does it worth an over-engineered mega system ?
Not to be confused with Uber's Zanzibar: <a href="https://github.com/uber/zanzibar" rel="nofollow">https://github.com/uber/zanzibar</a>
I’m curious about what their approach is to handle consistency with object creation and deletion in the client service. ie how do clients guarantee that the relevant ACLs are created and destroyed in Zanzibar when clients create and destroy their objects.<p>Destroy can be done asynchronously with durable messaging but asynchronous creation of ACLs is annoying from an api consumer perspective.
Is that a Metal Gear Solid[1] reference?<p>[1]: <a href="https://metalgear.fandom.com/wiki/Zanzibar_Land_Disturbance" rel="nofollow">https://metalgear.fandom.com/wiki/Zanzibar_Land_Disturbance</a>
Why did they name it Zanzibar?<p>Zanzibar is an island off the coast of East Africa known for being a place where people traded cotton for enslaved humans.<p>Not sure the connection.
Interesting choice of name.<p><a href="https://www.researchgate.net/publication/325605315_The_1964_Zanzibar_Genocide_The_Politics_of_Denial" rel="nofollow">https://www.researchgate.net/publication/325605315_The_1964_...</a><p>>On the fiftieth anniversary of the atrocious killing and raping of the Arabs of Zanzibar in the wake of the 1964 revolution in the Island, this paper sought to establish that this mayhem was genocide. In light of the almost complete failure to notice this tragedy, the paper pursued critical genocide studies and hidden genocide investigations to argue that this Arab tragedy in Zanzibar has been a denied genocide. Worse still, the paper showed that this genocide is commonly ignored even in studies devoted to bring to memory of hidden genocides life.
Somewhat off-topic I know, but I'd love to see this extended to some of the features that Sign in with Apple has in terms of private relay.<p>Signing in with Google yields (at a minimum) the e-mail address to the client which means that the list of third parties that have your e-mail (and can therefore spam you at will) is increasing exponentially. It would be great if Zanzibar extended the ACLs to include privacy controls with external services.<p>(Or I'm misunderstanding and this is only the component for internal Google authentication and not external federation for clients).
I can't get over the name because I definitely had a memorable experience going to Zanzibar in Toronto (<a href="https://www.yelp.ca/biz/zanzibar-toronto" rel="nofollow">https://www.yelp.ca/biz/zanzibar-toronto</a>) shortly after turning 19.