Moving forward with ORY Keto

[aeneasr]

I recently (re-)discovered the OPA project. This issue is about deprecating the ORY Ladon engine and aligning ORY Keto with OPA. The decision is not yet made and we are looking for valuable input regarding this.

OPA allows you to write authorization logic using a language specifically designed for that, called rego. Syntax is very go-like. Due to this, OPA is capable of providing all sorts of authorization mechanisms, like RBAC, ABAC, ACL, AWS IAM Policies, and more. In fact, I believe that ORY Ladon's logic is implementable using rego. I'm not sure if that holds true for conditions which still needs verification from my side.

Let's take a look at the current downsides of each project.

I believe that policy documents as implemented by ORY Ladon are very powerful, but also very complicated. Many developers struggle with proper resource & action naming. I think that regular expressions have their place here, but many developers struggle with writing and testing regular expressions and variable substitution is very flaky (currently only used in the ORY Oathkeeper adapter for ORY Keto iirc) from a ux perspective. Also, regular expressions do not scale well, especially if read from the database. I think we can fix this with caching, but that is not fixing the problem itself, only the symptom.

On the same hand, OPA is limited. I think rego is great for developers that really want to jump into this (like me). But it's a new syntax, new language, and new tools. I think the language is not incredibly intuitive and not always readable:

I believe that policy documents are, in general, quite complicated. In my opinion, rego has a steep learning curve as well. Can you tell me immediately what this does?

sod_roles = [
    ["create-payment", "approve-payment"],
    ["create-vendor", "pay-vendor"]
]

sod_violation[user] {
    role1 = user_role[user][_]
    role2 = user_role[user][_]
    sod_roles[_] = [role1, role2]
}

At least I can not - the point I'm trying to make is, you have to learn this.

OPA comes with a REST API but it's really a parser and execution engine. It parses rego files and executes the logic based on data you provide. The result is always true or false, depending on the authorization result.

The server is limited. It stores everything in-memory so pushing logic to the server is not realistic with more than one server running. Instead, you'll probably have to write a CI pipeline which builds a docker image that has all your policy definitions. IMO that can be very nice, especially if you have rego test as part of that pipeline. But, from my experience, most people do not want or know how to do these things.

Coming back to policies for a moment: Most developers do not need AWS IAM Policies, simple role management is enough. By the way, the Google Cloud Platform migrated completely to RBAC/ACL as well recently (at least in the UI) - very few people want to deal with complicated JSON documents. And many make mistakes, which is evident due to the many S3 leaks we're seeing recently (caused by misconfigured buckets, well really misconfigured AWS IAM Policies). I think the same would have happened if AWS used rego, or it would have probably caused less people to use this feature at all.

My vision for ORY Keto is to have a "policy decision point" (someone that says if something is allowed or not) that just works. I also believe that it should be possible to use several well-known patterns out of the box, this includes RBAC, ACL, ABAC and ORY Ladon Policies (for BC compatibility) and well, maybe your own rego definitions? I will experiment this month with different concepts and try to migrate Ladon Policies on top of rego. My preliminary tests showed that we can get a 10x performance improvement for simple use cases. We'll see how well this does for advanced ones.

We write this software is for you, so please participate in the discussion and leave your ideas and comments below.