Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zanzibar: Google’s Consistent, Global Authorization System (2019)

research.google

Post reply on HN
Print view View original

81–90 of 99 posts

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#81

Post by TechBro8615 »

rkangel wrote: post #53
jzelinskie wrote: post #50

Earlier quoted context omitted.

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 o…

> because now all of your microservices can query Zanzibar at any time This sounds a bit like a chokepoint. Is the important point here that Zanzibar is distributed and therefore is a good thing to be querying from all over the system (as supposed to one centralised application).

As someone who’s not the founder of an authorization provider, I’d tend to agree with you. Sure looks and sounds and quacks like a choke point!

But it’s also fundamentally hard to avoid isn’t it?

The challenge is that authn is so easy to implement statelessly, since you can verify a token anywhere you have a public key. But authz is far more complicated, since it requires an ACL list of arbitrary length along with the token. It’s not like GitHub can stuff a list of every repository I can access into my access token.

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#82

Post by TechBro8615 »

MrKristopher wrote: post #55
dvdkon wrote: post #43

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 approa…

I'm not sure I understand the concern here. Typically there is a logged-in user, and server asks Zanzibar if the user can or cannot access some document. Whether a certain document exists or not isn't typically a secret i.e. you might get HTTP 403 (forbidden) or 404 depending on whether or not the document exists.

This very much depends. GitHub for example will return 404 for a private repository when you are logged out. The idea is balancing HTTP semantics with information leaking.

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#83

Post by dvdkon »

joshuamorton wrote: post #76
dvdkon wrote: post #66

Earlier quoted context omitted.

Could you elaborate on "prior to the actual query"? Do you mean taking some rough queryable subset and then calling Zanzibar for each object in that subset? That's how I'm handling it right now, I just hoped others had a more scalable solution.

No I mean that a user either has access to the database or not. If they do, you check access prior to the query. I think you're doing something related to row level permissions within a database. And ultimately "Implementing side-channel secure row level security in a database" is a completely independent problem from "abstract authz checker, which is what zanzibar is. You might build a row level security infra atop…

From what I can see, Zanzibar is also intended for "row-level" access checks.

I also don't think it's such a separate problem. If you've got a set of authorization primitives, you should have some simple and foolproof way of applying them to various usecases. You might have the best policy description language and very fast evaluation, but what good is it as a central authz service when you can't securely implement search on top of it?

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#84

Post by 1cvmask »

etxm wrote: post #38
gneray wrote: post #6

I'm curious what's driving the resurgence in interest authorization infrastructure, particularly the Zanzibar paper. As founder of Oso ( https://www.osohq.com/ ), I have my own opinions, and I think this is a good thing. But would love to hear others' points of view here.

Never heard of Oso til now. I’m eval’ing a few tools, I really like your policy syntax!

Which tools are you looking at and what is your evaluation criteria?

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#85

Post by jzelinskie »

TechBro8615 wrote: post #81
rkangel wrote: post #53

Earlier quoted context omitted.

> because now all of your microservices can query Zanzibar at any time This sounds a bit like a chokepoint. Is the important point here that Zanzibar is distributed and therefore is a good thing to be querying from all over the system (as supposed to one centralised application).

As someone who’s not the founder of an authorization provider, I’d tend to agree with you. Sure looks and sounds and quacks like a choke point! But it’s also fundamentally hard to avoid isn’t it? The challenge is that authn is so easy to implement statelessly, since you can verify a token anywhere you have a public key. But authz is far more complicated, since it requires an ACL list of arbitrary length along with th…

>But authz is far more complicated, since it requires an ACL list of arbitrary length along with the token. It’s not like GitHub can stuff a list of every repository I can access into my access token.

This is exactly the problem that Zanzibar solves that makes it exciting! I've written about why giant lists of claims are not a good way to structure permission systems[0] and Zanzibar-inspired services do not function this way. Instead they ask you to query the API server when you need to check access to an item. All API calls return a response along with a revision. The response will always the same at a given revision, which means you can cache the response. If Zanzibar disappears, your app can function so long as content is not modified, which would force you to invalidate the revision. And that's only if you want consistency in your permission system -- a feature that not all permission systems even support. Most applications can tolerate just using the cached response regardless and relying on eventual consistency.

All of this is also ignoring the global availability of the Zanzibar service itself which it gets from using a distributed database like Spanner and replicating into data centers in every region in the world (which is why you want someone else to run it for you).

[0]: https://authzed.com/blog/identity-isnt-the-foundation/

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#86

Post by throwaway189262 »

rkangel wrote: post #53
jzelinskie wrote: post #50

Earlier quoted context omitted.

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 o…

> because now all of your microservices can query Zanzibar at any time This sounds a bit like a chokepoint. Is the important point here that Zanzibar is distributed and therefore is a good thing to be querying from all over the system (as supposed to one centralised application).

Contrary to microservice cargo cult, it's possible to build a relative monolith that scales infinitely. The bottleneck is the db, but if you have a schema where data is easily sharded you can scale it infinitely.

There's plenty of giant monoliths that scale fine. Like Google's analytics and gmail. If you have a database that can scale microservices are more about isolating code between different teams than any performance advantage

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#88

Post by jeffbee »

merqurio wrote: post #74

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. [0]: https://github.com/ory/keto

This comes up every time but I think it’s worth noting that Keto provides literally none of the consistency properties of Zanzibar. All of the distributed systems homework assignments for that project have been left as TODOs.

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#89

Post by sitkack »

TechBro8615 wrote: post #82
MrKristopher wrote: post #55

Earlier quoted context omitted.

I'm not sure I understand the concern here. Typically there is a logged-in user, and server asks Zanzibar if the user can or cannot access some document. Whether a certain document exists or not isn't typically a secret i.e. you might get HTTP 403 (forbidden) or 404 depending on whether or not the document exists.

This very much depends. GitHub for example will return 404 for a private repository when you are logged out. The idea is balancing HTTP semantics with information leaking.

Does the 404 a logged out repo return in the same amount of time as a repo that doesn't truly exist?
Post reply on HN