This article discusses the pioneering efforts by Ory to build the open source implementation of Google Zanzibar authorization system called Ory Keto.
Authorization is the process of determining who is allowed to do what in an application. Especially in critical global systems featuring human and machine actors with different sets of permissions it is still a hard problem to solve. In such a system, billions of permission checks have to be processed fast, reliably and consistently across many different environments.
The research paper describes how Google solved authorization globally and across all products:
"Zanzibar provides a uniform data model and configuration language for expressing a wide range of access control policies from hundreds of client services at Google, including Calendar, Cloud, Drive, Maps, Photos, and YouTube. Its authorization decisions respect causal ordering of user actions and thus provide external consistency amid changes to access control lists and object contents. Zanzibar scales to trillions of access control lists and millions of authorization requests per second to support services used by billions of people. It has maintained 95th-percentile latency of less than 10 milliseconds and availability of greater than 99.999% over 3 years of production use."
Problem Statement
Google needed a solution that would enabled them to continue to grow at a massive scale, but still respond within milliseconds - independent of location around the globe. They had a number of hard requirements for this to work, it had to be:
- flexible;
- low latency;
- large scale;
- always available and
- consistent.
A highly qualified team of researchers came up with a new type of access system,
later codenamed Zanzibar (originally it was
called ”Spice”).
”Spice” from the space saga “Dune” makes it possible to safely travel to other
planets and grants superhuman powers.
For cloud based services a globally spanning low latency access control system
is nothing short of a superpower.
At Ory, we knew we had to unlock this superpower free and open for everyone!
With the previous approach based on OPA
prior to 2019, Ory Keto reached some boundary conditions in both complexity and
scalability.
Many developers within our own community were also looking for a solution;
prompting us to study alternatives. There is also work in progress on some other
proprietary implementations of the Zanzibar paper, most notably by
authzed and
auth0. We believe this shows that there is
great demand for an open source solution that is community vetted and
transparent.
Building upon the knowledge that was available publicly, the Ory team devised a new generation of Ory Keto, with input and hard work from our awesome open source community.
Ory uses Keto as part of the Ory Platform, a comprehensive security system designed to meet the needs of sophisticated application developers seeking to provide cloud identity and access management in low latency infrastructure at scale.
Flexible
“When strangers meet, great allowances should be made for differences in custom and training.”- Frank Herbert, Dune
Ory Keto is designed with the goal to serve hundreds or thousands of different applications and services (it's clients). Each client may have different access control patterns, so it is crucial it works for all possible patterns.
Small applications with few users, resources and integrations have vastly different requirements than massive multi-national cloud services with millions of users. All kinds of services must be able to manage access control policies at any detail and in compliance with their internal data structure. Ory Keto needs to be able to understand and work with all policies.
A simple, but powerful data model provides the basis for this, combined with effective configuration capabilities.
This data model allows to define arbitrary relationships such as owner,
editor, and pays for between digital objects and subjects (like users).
In Ory Keto, Access Control Lists (ACLs) contain information on
is _subject_ allowed to do _relation_ on _object_.
object, relation and subject are all variables that can be defined as
required, together they form a
"relation tuple".
For the simplest case a relation tuple would be "user X has the relation Y to object Z". But ACLs can become much more complex for example "set of users X has the relation Y to object Z", while this set of users is defined as another relation tuple. So ACLs can contain other ACLs, for example to define that a set of users that can view a document is made up of the users that have been granted rights to modify that specific document as well as those who have viewing permissions for the whole folder of documents.
Low latency and high availability
”Delay is as dangerous as the wrong answer.” - Frank Herbert, Dune
Access control systems need to be secure, consistent and flexible enough to meet
the myriad of user demands.
They also have to serve high numbers of users around the planet, while ideally
being unnoticed and available at all times.
Authorization checks are usually in the path of the most critical parts of our
interaction with digital systems.
When a service wants to do something that could have dire consequences, delete a
table for instance, authorization checks should assure that the initiator are
really allowed to perform that action.
It is important to not confuse this with authentication (is this person who they pretend to be?). This question can be answered by Ory Kratos, which is a fully fledged modern identity management system.
In sophisticated cloud systems this can mean that thousands of authorization checks have to be made to serve a basic search response. If each of those checks takes only tenths of a second, round trips and waiting times can range in the minutes. This is bothersome when searching for something, but not acceptable when running critical infrastructure.
Worse, if the authorization system is offline, all requests have to be denied - completely blocking even basic interactions. Ory Keto was designed to be able to meet these demands spanning across clouds and environments.
Consistency
”A place is only a place.”- Frank Herbert, Dune
One concern is strong consistency. In distributed systems this means you always get the same response if you send the same requests to different parts of your system. This is opposed to "eventual consistency", which simplified means that you will get the same response once all updates are propagated.
In an ideal world all access control systems would be a strongly consistent
system.
The problem is, that this is clashing with other requirements, especially low
latency and high availability.
Because of the required strict data duplication, a strongly consistent system
can not achieve low latency worldwide. Also your access control policies are
probably not in the same physical place as the data you want to protect.
The solution is to use version snapshot tokens (short "snaptokens"). They allow
us to provide a strongly consistent response from an eventually consistent
system.
The basic idea is that all digital objects are versioned. Keto only answers
allow if access to this specific version is granted. After an ACL update is
issued (grant or revoke permissions), there is a short period until the update
propagates. The snaptokens ensure that the system only ever wrongly answers
allowed if the permission on the requested version was previously granted.
This requires the application to store the snaptoken next to every object
version and provide it on every access check request. In essence, Keto
guarantees that an entity can only access objects they currently have access to
and the exact versions of the objects they used to have access to.
For example a common scenario is that a user had access to a previous object
version, but then access was revoked to the object. During the propagation time
the system can still answer allow for the old version as defined by the
snaptoken. But when newer object versions are requested, it will always be
denied.
Similarly, the system might answer deny for older object versions if access
was granted later on, but will always answer allow for object versions younger
than the last ACL update.
This means that the system is not only consistent within itself - same requests lead to the same response in different parts of your system - but also in sync with data object changes.
One important point is that Keto can be operated locally as well, which means there are no database sync delays.
Currently snaptokens are not implemented in Ory Keto, but all the concepts have been worked out and integrated into the design already. Actual consistency guarantees will be added soon.
Conclusion
”The spice must flow.” - Frank Herbert, Dune
So far the Ory Keto effort implements:
- Access Control Language
- Data model
- Example configurations
- Read / Write / Check / Expand API
- Namespaces
In the near future:
- Consistency guarantees using snaptokens
- Globe spanning cluster operation mode
- Interoperability with other Ory products including Hydra and Kratos
Also check our Implemented and Planned Features documentation for more information.
If you are interested in seeing what this software package can do, you might
want to check out the
quickstart example and the
full feature example.
Also read more about the
concepts implemented in
Ory Keto.
Ory, a multi-cloud SaaS platform, aims to advance the state of zero trust
security by making it easier and safer for developers to implement a number of
boilerplate services such as ID management, credentials, service authorisation,
authentication, rule based reverse proxy and access control in a low latency
access system.
Ory has years of open source software experience with a global community of
contributors, leading zero trust security products such as
Ory Hydra, and tens of thousands of satisfied users
worldwide.