{"action":"created","issue":{"url":"https://api.github.com/repos/ory/keto/issues/47","repository_url":"https://api.github.com/repos/ory/keto","labels_url":"https://api.github.com/repos/ory/keto/issues/47/labels{/name}","comments_url":"https://api.github.com/repos/ory/keto/issues/47/comments","events_url":"https://api.github.com/repos/ory/keto/issues/47/events","html_url":"https://github.com/ory/keto/issues/47","id":356693848,"node_id":"MDU6SXNzdWUzNTY2OTM4NDg=","number":47,"title":"Moving forward with ORY Keto","user":{"login":"aeneasr","id":3372410,"node_id":"MDQ6VXNlcjMzNzI0MTA=","avatar_url":"https://avatars3.githubusercontent.com/u/3372410?v=4","gravatar_id":"","url":"https://api.github.com/users/aeneasr","html_url":"https://github.com/aeneasr","followers_url":"https://api.github.com/users/aeneasr/followers","following_url":"https://api.github.com/users/aeneasr/following{/other_user}","gists_url":"https://api.github.com/users/aeneasr/gists{/gist_id}","starred_url":"https://api.github.com/users/aeneasr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/aeneasr/subscriptions","organizations_url":"https://api.github.com/users/aeneasr/orgs","repos_url":"https://api.github.com/users/aeneasr/repos","events_url":"https://api.github.com/users/aeneasr/events{/privacy}","received_events_url":"https://api.github.com/users/aeneasr/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":11,"created_at":"2018-09-04T07:57:23Z","updated_at":"2018-09-14T07:35:15Z","closed_at":null,"author_association":"MEMBER","body":"I recently (re-)discovered the [OPA project](https://github.com/open-policy-agent/opa). 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.\r\n\r\nOPA 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](https://www.openpolicyagent.org/docs/comparison-to-other-systems.html). 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.\r\n\r\nLet's take a look at the current downsides of each project.\r\n\r\nI 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.\r\n\r\nOn 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:\r\n\r\nI 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?\r\n\r\n```\r\nsod_roles = [\r\n    [\"create-payment\", \"approve-payment\"],\r\n    [\"create-vendor\", \"pay-vendor\"]\r\n]\r\n\r\nsod_violation[user] {\r\n    role1 = user_role[user][_]\r\n    role2 = user_role[user][_]\r\n    sod_roles[_] = [role1, role2]\r\n}\r\n```\r\n\r\nAt least I can not - the point I'm trying to make is, you have to learn this.\r\n\r\nOPA 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.\r\n\r\nThe 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.\r\n\r\nComing 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.\r\n\r\nMy 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.\r\n\r\nWe write this software is for you, so please participate in the discussion and leave your ideas and comments below."},"comment":{"url":"https://api.github.com/repos/ory/keto/issues/comments/421259120","html_url":"https://github.com/ory/keto/issues/47#issuecomment-421259120","issue_url":"https://api.github.com/repos/ory/keto/issues/47","id":421259120,"node_id":"MDEyOklzc3VlQ29tbWVudDQyMTI1OTEyMA==","user":{"login":"aeneasr","id":3372410,"node_id":"MDQ6VXNlcjMzNzI0MTA=","avatar_url":"https://avatars3.githubusercontent.com/u/3372410?v=4","gravatar_id":"","url":"https://api.github.com/users/aeneasr","html_url":"https://github.com/aeneasr","followers_url":"https://api.github.com/users/aeneasr/followers","following_url":"https://api.github.com/users/aeneasr/following{/other_user}","gists_url":"https://api.github.com/users/aeneasr/gists{/gist_id}","starred_url":"https://api.github.com/users/aeneasr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/aeneasr/subscriptions","organizations_url":"https://api.github.com/users/aeneasr/orgs","repos_url":"https://api.github.com/users/aeneasr/repos","events_url":"https://api.github.com/users/aeneasr/events{/privacy}","received_events_url":"https://api.github.com/users/aeneasr/received_events","type":"User","site_admin":false},"created_at":"2018-09-14T07:35:15Z","updated_at":"2018-09-14T07:35:15Z","author_association":"MEMBER","body":"Hm, interesting, thank you for the comparison! I will definitely check out casbin too, it looks promising. Especially the *\"You can also write your own Golang function and let Casbin use it\"* is something we need to properly implement a BC-engine for ladon."}}
{"actor":{"display_login":"aeneasr"}}