Keto for UI permissions

[ysaakpr]

Keto is getting wider adoption in the recent on open source application stack. Wondering how would we achieve UI/ Browser APP/ Mobile app level UI permission control using Keto. As of today there no well defined way to use keto for frontend permission checks. Frontend UI permission handling usually be like

1. If user can do action1. show button else don't show button
2. Hide a component if user has a role

All of these kind of decisions need to be taken care and one UI page can have 10s or 100s of such UI decisions, depending on different user scenarios. Having Keto api wont help in these cases(will add so much latency), and would have to review how to allow such a system can take support from keto.

[zepatrik]

Thanks, this is indeed a use-case that is not yet well discussed. Some ideas I have around that:

1. Mircoservices (API gateway'ish): Treat Keto as one of your microservices and use it's API to assemble the response for the front-end.
2. More specialized Keto API: It could be possible to add a "bulk"-check API. In such a front-end oriented setting it can be assumed that most checks will actually be for the same subject and potentially even object (as you render all buttons in the context of the current object). In that case Keto could optimize evaluation by doing all checks at the same time. The set of relation tuples to check will at least partially overlap and therefore be available/expanded already.
3. Session/stream API: For reasons described in 2. there is a high probability that relation tuples can be reused for checks within a bound context and time. This could be specifically signaled by the client itself by using a kind of "session" or maybe stream-oriented API (websocket?) that explicitly builds and shares caches between API calls.
4. Lazy-loading on client side: This probably makes sense anyway regardless of Keto and 2., but some guidance on how to get started would probably make sense.

In general there should not be much of a problem for front-ends to talk to Keto directly. In cases where 100s of checks are needed at the same time Keto might get into trouble a bit, but that is up for experimentation. Especially with aggressive caching (#312) this should still work out fairly well, as it can be assumed that the set of tuples required for a check will be in cache with a high probability.

[landerss1]

We are in a similar situation. The way we have chosen to approach this is:

1. Create a RBAC model, as described in discussion here. We are currently on an old version of Keto, but are working on a migration to 0.6. What the discussion doesn't reveal is that we, besides Apis and Endpoints, also model access to data. For example, if we want to model permission to modify attribute X of object Y, it could be modeled as /data/objecty/attributeX in the same way as an api endpoint.
2. The RBAC model is used in the API gateway to control access to endpoints
3. In the RBAC model, we have policies. This is similar to what our product owner and front-end guys refer to as features. So we will treat features as policies.
4. We have a REST api that implements the /userinfoendpoint of the OpenID specification, which is being called during login, and that endpoint returns the permissions of the user. So, depending on your needs, this can be the policies (features) and permissions the user have. Then, the front-end would keep these in local storage for a certain time period and use it to make the appropriate checks to decide on how to render the UI.
5. As we are using features, and in some cases fine-grained permissions, we don't have more than a few checks that need to be made on each page in the UI. In your case, it sounds like you are using a very fine-grained policy system. Do you really need that, or could you maybe work with different features instead? In our case, we have found that the existence of a feature controls most of the appearance of a page, rather than having to check for each and every one of the form controls on the page.

[zepatrik]

Thanks for the insights @avamonitoring, this is also what I expected as a typical use case. Very helpful :+1:

[github-actions[bot]]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan on resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneous you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️

[quizmoon]

@zepatrik is there any way using stack of Oathkeeper + Kratos + Keto to implement "mix" of your ideas (#2 and #3) to create analog of Kratos's "to_session" based on Keto's "Query relation tuples" to retrieve list of permission only for SubjectId we got from Kratos session? This way once page opened request actual list of permissions, with filters by namespace, object for specific SubjectID. Then it will be possible to handle this array on UI side display the elements correctly without need to check every permission separately.

[zepatrik]

If you manage to assemble the list using queries only, sure. I guess you still have to write a bit of glue code to make the right queries. We are actually planning to add an API that is the reverse of the current expand, so it gives you all objects a specific user has a specific relation to. I cannot give out a concrete timelline, but we aim for the next few months.

tl;dr what you propose is a good workaround for now

[github-actions[bot]]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️