Allow defining ABAC relation tuples

[zepatrik]

Is your feature request related to a problem? Please describe.

ABAC rules can not be added simply with relation tuples as the attributes have to be checked.

Describe the solution you'd like

In general, the database will not be the only source of relation tuples.
For subject set rewrites we will have to dynamically generate relation tuples that are used for evaluation of requests.

ABAC rules can be added dynamically the same way depending on the actual attributes of the request context.

An example ABAC rule: allow write access to repository form sub net 192.168.2.0/24

This would translate to the following relation tuples (omitting namespaces):

repository#write@<192.168.2.0/24#accessing-from>    <- fixed tuple always present
192.168.2.0/24#accessing-from@user                  <- dynamic tuple added based on attributes of the requests

These dynamic tuples only have to be computed initially on request. It would be best to have the client define them so that Keto does not have to support parsing 1000 different data formats and queries on them.

In essence, the client would translate any attributes it likes into relation tuples that then are used by keto for evaluation.
In general, the client can add relation tuples dynamically only for single requests.

The check/expand API would have to get an additional parameter for dynamic relation tuples.

Describe alternatives you've considered

Keto should not support a complex language with an even more complex engine like OPA. Any other idea for implementing ABAC should be collected in this issue.

[robinbraemer]

So, having Open Policy Agent already there to be able to do all the complex attribute based authorization control...

• Should we even have ABAC in Next Gen Keto?
• If yes, what would be the beneficial difference Keto offers compared to using Open Policy Agent +Keto ACL extention?

I think the Open Policy Agent +Keto ACL extention pair (OPA+Keto) is just so endlessly powerful 🎉 that pretty much anything, including ABAC, RBAC, etc. can already be configured by users in rego. (...having #318 is just too exciting 😍)

The only thing may be useful Keto could provide in addition to ACL is an API for RBAC (literally just an API) using ACL as backend as planned, but even such opinionated RBAC API might be too constrained and not suffice all users needs as can be self-built with the OPA+Keto combination.

Maybe just provide documentation of how to use OPA+Keto to build highly customized RBAC, ABAC, ... systems for those ORY users that need it? @aeneasr @zepatrik

[aeneasr]

The problem with OPA is that it does not have any persistency, so one problem will definitely be the management of resource definitions in OPA, especially if we're looking at high scale. But I generally agree that we should not try to come up with too much fancy stuff here as it will make everything more complicated and bespoke.

[zepatrik]

This could be achieved also by allowing a check request to pass a list of subjects. A simple case is where * is interpreted as a special subject that anyone can impersonate. Tuples can then be added accordingly to reflect the permissions of anonymous users. A request for user foo would then be transformed by the client to the check request: object#access@(foo|*)?.

This can then be used to add all the states a user can currently impersonate (e.g. by checking for some attributes) to the actual request:

let subject = [user.userId]

if (user.isAtWorkLocation()) {
    subject = [...subject, "special at work user id"]
}

return keto.check({ object, relation, subject })

with the Keto relation tuples in the database:

disclosed_object#access@special_at_work_user
not_disclosed_object#access@user_foo

This could then be leveraged using all the set operators theoretically available in subject set rewrites to build even boolean operations on these subjects.
This would probably work way better in a setting where you have many attributes that a user can have, while the first idea would be less complex to set up with view attributes.
This would not solve integration with other services (like OPA), I guess.

[robinbraemer]

A am not fully against ABAC support, but yet I think we might are going in an unsuitable direction with builtin ABAC support for ACL or likewise ideas. Zanzibar is not even designed to do this at its lowest level.

I don't quite see the vision of Keto's builtin ABAC system, because of the question:

• If one can use OPA+KetoACL (Allow defining ABAC relation tuples #319 (comment)), can we still deliver actual value to Keto users with a standalone and fairly limited Keto ABAC?

We know that building a ABAC-supporting system is hard to get right and generic enough that users can highly adjust it to their unique use cases where whatever system they are building, such ABAC provider can output an arbitrary decision given arbitrary request input (not just "He is allowed to do this"). That's why OPA exists.

If I did not miss anything discussed and from my perspective, I see the biggest potential for Keto lays in ACL for the following reasons:

• If this project can put all efforts and focus of the Keto on getting ACL efficient and reliable, yet adhering to its simple API, we can solve the most crucial problems in most access control systems: decisions at scale

• That's why we shouldn't even think about implementing ABAC(-ish) solutions into the early Keto versions and instead provide all the glue (extentions/integrations and docs/tutorials) to ignite the probably incorrigible and most poweful open-source access control system combination one could bring most value:

  • Open Policy Agent + Keto ACL.

• Where OPA gives all the flexibility to use Keto's distributed ACLs for sub-decisions executed in the OPA's policy engine.

  • OPA's scalability issues are compensated by Keto ACL
  • Keto's policy/decision limitations are compensated by OPA

As much as I would like to think that, there can't be done much more improvement and I don't see a successful ABAC implementation within Keto. (Remember: Google's Zanzibar is a base-system - and so should Keto, I think).

[aeneasr]

Hm, I kind of agree with you @robinbraemer . Thinking about ABAC now is a good step forward, but we have yet to specify the user set rewrite configuration layout, figure out the scalability architecture, and more. Bending concepts of the ACL to solve this is maybe not the best path forward for the moment. Maybe we should keep it in the back of our heads and include it when planning new APIs, but not actually implement or talk about it yet.

Also, I would not fixate too hard on OPA.� I love the project and the people behind it, but so far the project has been quite disappointing when actually using it. Getting the policies right is hard (learn a new programming language that is quite different from others due to its query structure), it is difficult to make changes persistent at scale (because it is not a concern for OPA), latency has been an issue from day one (and not yet solved unless you have maintainer level knowledge of rego parsing internals), and resource consumption is exorbitant for certain types of operations and datasets because everything is loaded in memory.

[zepatrik]

I am 💯 % with you there, I was afraid already that my comments are not clear enough.
Basically, both of the ideas presented above try to find an idea of how to integrate Keto with any other service. This would allow ABAC but also many other things. The only thing that would change in Keto would be one of:

1. accept temporary ACL rules that are just considered for a single request
2. allow to specify multiple subjects for a request, Keto will return "allowed" if any of the subjects is allowed

Keto would still not have any ABAC related features, it would just be very easy to add another service that allows that.