Live data from Hacker News

Why Google Zanzibar shines at building authorization

blog.warrant.dev

31–40 of 91 posts

Re: Why Google Zanzibar shines at building authorization

#32
post #21

One thing I find difficult using access control systems as a distributed service like Zanzibar is a convenient and performant way to search and filter resource data using permissions. For example defining database queries that should only return resources a subject has access to based on Zanzibar permissions.

SpiceDB/Authzed has "Lookup"s. There's LookupResources for finding what a user has access to, and LookupSubjects now too to see who has access to a resource. Great capability. https://authzed.com/blog/lookup-subjects

Re: Why Google Zanzibar shines at building authorization

#33

The Zanzibar paper has a section on the consistency model, which says that the race conditions outlined are solved by respecting update order. It then solves it by using Spanner as underlying storage (which is kind of lazy). How does Warrant deal with consistency?

Why is it lazy? Seems like leveraging a tool Google built for distributed systems specifically for consistency guarantees.

As I understood it from context, the word lazy was being used to complain that the reference to Spanner wasn’t in-lined.

Re: Why Google Zanzibar shines at building authorization

#34
Very happy to see industry discover the power of graphs and especially, a triple-based representation (cf. RDF [0]; subjects are “subjects”, relationships are “predicates”, and objects are “objects”).

Now, a genuine question: why try to shoehorn a freeform graph (because the list of relationships is not hardcoded) into a relational DB instead of using a graph DBMS like Neo4j, Apache Jena (Fuseki) etc. From looking at the source code briefly [1], I didn’t see any extreme SQL optimizations. This indicates to me that Warrant would either support a very limited set of query types, or be very slow on quite a few types of them. Also see “billion triple challenge” in the academia around this.

Good luck with your startup!

[0]: https://www.w3.org/TR/rdf11-primer/

[1]: https://github.com/warrant-dev/warrant/tree/main/pkg/authz/o...

Re: Why Google Zanzibar shines at building authorization

#35

We successfully used a Relationship-based Authorization System based on the Zanzibar paper at my last job building a B2B SaaS leaning heavily on cross-company integration. The flexibility in defining rules through tuples helped us iterate rapidly on new product features. We used self-hosted Ory Keto [0] instances as the implementation, though we would have preferred a managed solution. We were checking out Auth0 Fine…

Can anybody explain me why there seem to be much focus on scalability in this context? I mean we have 8 billion people. If the whole planet registers, home PC can handle it, plus it partitions beautifully if necessary in case of authentication. So what am I missing?

Re: Why Google Zanzibar shines at building authorization

#36
post #35

We successfully used a Relationship-based Authorization System based on the Zanzibar paper at my last job building a B2B SaaS leaning heavily on cross-company integration. The flexibility in defining rules through tuples helped us iterate rapidly on new product features. We used self-hosted Ory Keto [0] instances as the implementation, though we would have preferred a managed solution. We were checking out Auth0 Fine…

Can anybody explain me why there seem to be much focus on scalability in this context? I mean we have 8 billion people. If the whole planet registers, home PC can handle it, plus it partitions beautifully if necessary in case of authentication. So what am I missing?

Forget about 8B people in this context. If you have 1000 microservices in the company and each has 100 rps, you are looking at ca. 100k rps to a Zanzibar-style system to authorize every request (not to authenticate a user).

Re: Why Google Zanzibar shines at building authorization

#37
post #35

Earlier quoted context omitted.

Can anybody explain me why there seem to be much focus on scalability in this context? I mean we have 8 billion people. If the whole planet registers, home PC can handle it, plus it partitions beautifully if necessary in case of authentication. So what am I missing?

Forget about 8B people in this context. If you have 1000 microservices in the company and each has 100 rps, you are looking at ca. 100k rps to a Zanzibar-style system to authorize every request (not to authenticate a user).

Thanks.

Re: Why Google Zanzibar shines at building authorization

#38

Very happy to see industry discover the power of graphs and especially, a triple-based representation (cf. RDF [0]; subjects are “subjects”, relationships are “predicates”, and objects are “objects”). Now, a genuine question: why try to shoehorn a freeform graph (because the list of relationships is not hardcoded) into a relational DB instead of using a graph DBMS like Neo4j, Apache Jena (Fuseki) etc. From looking at…

Is Neo4j a good option? I've not heard great things about it performance-wise, though this was some years ago when tinkerpop/gremlin was starting to make news in my circles, and we were operating on extremely dense graphs.

Re: Why Google Zanzibar shines at building authorization

#40
post #22
post #16

I was super curious to hear how Zanzibar is being used to control access to buildings. Don’t be fooled, this is not that post. ;)

I was super curious to hear why the Zanzibar office of Google was somehow better at authorization than e.g. their Mountain View office.

At least one Google office I know has building access controlled by Zanzibar.
Post reply on HN