Hello! I am one of the maintainers of Ory Keto. We spent a lot of time and effort to read, learn, and analyse the Google Zanzibar paper (https://research.google/pubs/pub48190/) and the release brings that all together. There are still many things missing, but with a great community we hope to build the “Kubernetes” of permissions and access control! If you have any questions, I am here to help
Full Disclosure: I'm a YC W21 founder that's built authzed, which is effectively Zanzibar as a Service, but anything that gets mindshare towards using ACL services is huge.
How close do ya'll plan to follow the paper? At a glance, I noticed a few of differences.
It'd be amazing if we had API compatibility across our products.
We tried to follow as close as possible, but left out all optimizations and cluster inter-node messaging for now. The data structures and APIs are followed 1:1.
In some places it was hard to follow the paper as they leave out important details, but you probably experienced that as well ;)
Your APIs look quite compatible, as you probably also stayed very close to the paper.
Amazing, I was going to start such endeavour, Zanzibar is to me that best of the ACL system that I know of, from a theoretical flexibility perspective. However, I was thinking of taking the principles but actually represent the triples as RDF and use SparQL to represent policies, to use the power of graph engines rather than building my own triple store & query engine. Any reason you went for SQL storage and a custom query engine/language on top?
I don't work at ORY, but I do work on a Zanzibar implementation.
Basically, what you're describing is called "GBAC".
GBAC can be great if you need the full power of a typical Graph API, but Zanzibar-like services are focused on solving the problem of finding a path between two edges[1] and doing everything you can to optimize that operation for latency.
GBAC is flexible, but at the cost of performance compared to something more structured.
How did you land on the Zanzibar architecture over other choices?
Full disclosure: I'm cofounder/CEO of Oso (https://www.osohq.com/), a library for authorization. Overall, it's incredible to see all the activity around authorization recently.
@gneray we started ory/keto with the OPA implementation, then added AWS IAM conventions. Last year we started with Zanzibar since we appreciate the powerful simplicity and the architecture pattern for wide scale geographic deployment. With the previous approached there were some scaleability problems. Now ory/keto evolution does all of the above. check it out on GitHub.
how do you see zanzibar being able to complement kubernetes? what if any integration points will there be? or does ory keto &c intend to provide only application level permissions & access, not ops permissions & access?
We see it as a very universal service, so integration with k8s is definitely on our list, but there are no concrete plans yet. The ACLs are just so generic, you can describe anything with it.
It's a impressive example of high functioning discourse: all the participants provide valuable insight, state concerns, elegantly summarize very complex issues, and show a lot of respect to each other; great gains are made as a result. It's worth reading in its entirety.
This looks great, good to learn that something like this is out there.
I work at Auth0 and we are building a Zanzibar inspired SaaS as well (you can read here if interested https://twitter.com/auth0lab) and it is positive to see that there's interest in services like this, it's validating :)
One of the things we found is that learning Zanzibar concepts can be a bit daunting, so we put together this playground: https://sandman-86.herokuapp.com/, that has samples and tutorials, etc.
Hopefully that's useful for others getting started with Zanzibar. We are likely going to be adding the ability to write to the playground (it is read-only today) in the next few months.
I went diving into the docs to find out how Keto implements Zanzibar's consistency guarantees, which for Zanzibar are provided mostly by Spanner, but it seems that Keto just does not[1]. This does not strike me as the kind of thing that can just be added after the project begins.
So the idea in the paper is that you store a version token (aka. zookie) next to every object version. When you ask Zanzibar if a user is allowed to modify it, the request contains the stored token. Then you get a new token with a successful response that you store with the new version. This guarantees that a user can only access 1. objects they have access to and 2. objects they don't have access to but only at versions they once had access to. The second case only occurs until an ACL update propagates around the globe and through all distributed caches. In our opinion that can be added later on (the proto definitions already account for that), although it is a breaking change of course.
One important point is that Keto can be operated locally as well, which means there are no database sync delays. This is the only mode it supports right now, and it does not need the zookies for that.
If you are interested in seeing what this software package can do, as I was, you might want to check out the quickstart example: https://www.ory.sh/keto/docs/quickstart
Keto only does authorization, independent of users, devices, bots, applications, ... Basically you store your ACLs there and then ask "is _subject_ allowed to do _relation_ on _object_". All the variables are whatever you define them to be.
Kratos can manage users and groups right? Looks like it requires a database backend today. I have been noodling what a distributed AAA service like kratos might look like--any plans to leverage etcd instead?
What about managing auth for (Linux) servers? PAM, sudo, etc?
Do any of the ORY products provide a UI? From what I've seen of Kratos, you have to completely implement all HTML output yourself. Is that accurate? Is there some drop-in UI in the ORY ecosystem?
Exactly, all of our products come without any UI whatsoever. There are example UIs that could be improved, but they can get you started easily. Something like stripe's hosted pages is on our list, just not had the time to implement it yet.
Hi - as someone who's been on the keto diet a lot over the pandemic and also in the before times - just wanted to chime in saying, you're going to have a heck of a time trying to break through the mountains of pages + SEO about keto recipes/books. I'd really suggest calling this something else.
Hm good point. The project itself exists already for quite some time now, this is just a complete rewrite. It is named after an ancient Greek goddess: https://en.wikipedia.org/wiki/Ceto (all of our projects are named after Greek mythology).
Joking aside, I dislike stuff that reuses overly generic concepts and names. I get why it was chosen, it's sorta cute, and it fits the theme, but it would be very nice if it was a uniquely named concept.
I have friends who's job it is to come up with names for new drugs. It's actually a difficult task, since it needs to be easy to remember, create a slightly positive or neutral association with consumers, and most importantly, not be even close to a dirty/offensive word in any language used in a major market
It does result in some super silly names. So much so, that when I studied pharmaceutical sciences, we made a drinking game called "Pokémon or Drug"
> Patients can wind up taking the wrong prescription if a pharmacist mistakes Foradil, which treats bronchitis, for Toradol, which relieves pain from arthritis, or mixes up the blood-thinner Plavix with the antidepressant Paxil.
It's really awesome to see the Zanzibar implementation open sourced. I also built an implementation of Zanzibar. From my understanding, one of the core features of the paper is the Leopard index system which delivers fast permission checks at scale. I noticed that your system doesn't have an index algorithm, but there is an issue in your repo to implement it. Do you have any idea when you would implement it? I'd like to potentially use/contribute.
@atainter56 the Leopard Index System is on the roadmap. Initially our focus is the ACL implementation, and now the deployment and scaleability will be prioritised. Please join our GitHub and Slack Community and be part of the solution.
Do you plan to add ABAC permission policies consisting of an expression of arbitrary attribute-based conditions for the object? Say 'o.group = 'guest' AND o.location in ['CA', 'WA'].
Recently a prospective client, coming from the world of Active Directory, has expressed a need for such a feature in ASPSecurityKit.
I haven't read the Zanzibar paper, but In ASPSecurityKit we've implemented ACLs on a similar concept – we call it activity-data authorization (ADA) [0]. Since it works as part of your application as a library, it can inspect request and automatically discover and authorize access to objects [1]. The attribute-based permission policies for users is something we're evaluating now.
Basically the idea is to check the attributes before actually forwarding the request to Keto. That could be done through e.g. a OPA integration. This can scale much better IMO than just doing everything in OPA.
OPA takes a whole different approach. They basically have a specific language and a corresponding interpreter. The previous version of Keto was based off of OPA. We discovered that it is not suitable for our needs and what we want to offer because it can be very hard to meet certain performance goals (e.g. https://github.com/ory/keto/issues/104)
Taking this simple approach allows us to provide a global, low latency, and consistent authorization system.
It's a really well designed distributed system for calculating access control decisions at scale. It makes a specific authorization CAP tradeoff that allows for consistency around access checks to different "versions" of a piece of content, allowing older content to be protected by checks served from read replicas and cache.
Full disclosure: I am a co-founder of a company building and hosting a Zanzibar implementation as a service: https://authzed.com
In the case of Authzed, we provide a gRPC API [0] which can be used from any application or language that supports gRPC, as well as designed client libraries for specific languages [1] to make integration even easier.
Applications primarily integrate by making Check requests [2] at any point in which a protected resource is being accessed and Write requests [3] at any point in which permissions are granted or removed.
OAuth is just an identity tool (to say a login is a certain person). Zanzibar can be seen more as a ACL system that you can put across your system. So it is there to validate that a given user is able to access any specific resource.
But your docker files are not really related to the source code. Your Dockerfile expects a prebuilt binary, and your docker-compose file a pre-built image from a container-registry (usually Dockerhub).
It would be better to do building of the project in a multi-stage Dockerfile [1], and use the local Dockerfile [2] instead of a pre-built image from Dockerhub.
There's already 50 of these things that have different features/providers/etc. Can't we stop making 50 different ones and just focus development on one of them?
Edit: My bad, it's a corporate product, they're not gonna focus development around somebody else's code. Corporate "open source" is hopeless.
if there was more agreement anything we had was genuinely good i might allow it, but atm it's pretty clear there is much work to do, none of it is lock on solid yet. so many differing approaches are necessary.
I also think you've struggle to name a dozen commonly popular authorizers.
Not related to Ory: I don't know why the name of the Google's service is Zanzibar but if that's related to Zanzibar Island which was once a slave route, I don't feel good about it. I'd love to be enlightened on this part. You can call it my curiosity to know.
