What is the status of xacml based solutions? Anyone using it?
Zanzibar: Google’s Consistent, Global Authorization System (2019)
51–60 of 99 posts
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#52I'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…
What exactly is the attack you're worried about here?
Why do attackers have direct query access to your database? What useful information can they extract from knowing there is an unauthorized object in the database?
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#53Maybe 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 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).
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#54I'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…
The problem isn't the 30 lines, though. The problem is "millions of users, billions/trillions of objects" and both are non-hierarchical with pairwise sharing etc. If the requirements were simple, the POSIX model would still work too :)
I agree. for my use case, once a user is authenticated, you get his roles and subscription. There's a limited number of features or actions for each object type, and a limited number of object types. So you can get the set of rules in the client to manage UI, and apply the same set of rules on the backend in the API.
In this use case the authz calculation time will be the same with a million users and a billion objects.
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#55I'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.
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#56Maybe 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…
You can and it doesn't have to be a choke point; as far as the ACL is concerned it's just a namespace (the microservice) and an opaque ID inside that namespace.
What the Zanzibar paper describes is two big things:
(1) The auth service gives those microservices an ability to set their own inheritance rules so that you do not need to store the fullest representation of those ACLs. If you are propertly targeting the DDD “bounded context” level with one bounded context per microservice, then in theory your microservice probably defines its own authorization scopes and inheritance rules between them. (A bounded context is a business-language namespace, and it is likely that your business-level users talking about “owners” in, say, the accounting context are different than the users talking about “owners” in a documentation context—or whatever you have.) Some upfront design is probably worthwhile to make the auth service handle that, rather than giving the clients each a library implementation of half of datalog and having each operation send a dozen RPCs to the auth service for each ACL check.
(2) The microservices agree on part of a protocol to allow some eventual consistency in the mix for caching: namely, the microservices agree that their domain entities will store these opaque version numbers called zookies (that the auth service generated) whenever they are modified, and hand them to the auth service when checking later ACLs. This, the paper says, gave them an ability to do things like building indexes behind the scenes to handle request load better, without sacrificing much security. Most of the ACL operations are going to not affect your one microservice over here because they happen in a different namespace or concern different objects in the same namespace: so, I need a mechanism in my auth service to tell me if I need an expensive query against the live data, or if I can use a cache as long as it's not too old.
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#57Earlier 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).
The novel aspect of the Zanzibar paper is its application of
distributed systems principles to avoid such a chokepoint. This includes not only the design of the service itself, but also the consistency model used in the APIs that are consumed by applications that make many operations cacheable.
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#58This 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. [0] https://news.ycombinator.com/item?id=20132520 [1] https://news.ycombinator.com/item?id=26738344
Airbnb Himeji also: https://medium.com/airbnb-engineering/himeji-a-scalable-cent...
I am continuing to be amazed at how much over engineering Airbnb does for ostensibly a cleaner couch surfing broker. Like they don't actually do much even for a travel site, they have so much investment and could have easily disrupted so many different travel related Fields instead they keep over engineering software. Not sure how to feel about it (since we do kinda benefit from their busywork)
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#59Earlier quoted context omitted.
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.
I use OPA with terraform and kubernetes, but I’m looking for something for application ACLs, where I as a resource owner can assign permissions to arbitrary subjects for a resource.
Does OPA support that? If so that would be very very cool.
Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)
#60Should add "(2019)" to the title