neupatr

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.

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.

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.

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.

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.

Check out https://github.com/ory/kratos, our identity server. Or https://github.com/ory/hydra, our OAuth2 server. All of them together can be assembled to have something like Keycloak.

Thank you ;)

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).

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