-
Hi, We have tried to implement a simple RBAC model for use in the Krakend API gateway, where we have developed a simple plugin that use the gRPC endpoint in Keto to check access. The model we have implemented in Keto is this: A user is a member of one or more roles. The roles have access to policies. The policies are statements that the policy have either read or write access to an entire API, or a specific endpoint in the API. So we have User -> member -> Role -> access -> Policy -> read/write -> API -> parent -> Endpoint An example with payloads:
Being new to the notion of relation tuples, I'm not sure if this is the intended way to implement RBAC, but it seems to work, even though I haven't tested it enough to be sure. But, with this model I can check if a certain user/role/policy has access to a specific endpoint in an API. And, using the expand API, I can see who has access to a specific endpoint. However, I can't figure out how to use the List API to see what endpoints a specific user/role/policy can access. Is the List API supposed to support that type of queries? The expand API doesn't seem to work either in this scenario? We intend to build a UI to support defining and maintaining roles and policies, and without being able to list the apis/endpoints that are accessible to a user/role/policy in an easy way it becomes tricky. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
Nice, that looks very good 👍 One small thing: some of your tuples (e.g. Regarding the list API, it's purpose is to list the tuples exactly as they are stored, so no expansion of subject sets. You can specify the parts of the relation tuple that you know. So calling [
{"namespace":"permissions","object":"/apis/my-api","relation":"read","subject":"policies:/system/my-api/*/rw#access"},
{"namespace":"permissions","object":"/apis/my-api","relation":"write","subject":"policies:/system/my-api/*/rw#access"}
] which you then have to manually follow further (probably interactively through the UI). You probably already read the docs pages but I will link them for completeness: |
Beta Was this translation helpful? Give feedback.
-
Thanks for your reply. Yes, I understand the difference between a subject id and a subject set. I included them both in the model so I always can check if a specific subject has access to a permission. So, e.g., I can check if a policy has read access to an API, but I can also check if someone who has access to a policy also has read access to an API. That comes from a few hours of experimenting with the use of '#' and '#access' and '#read' etc. in the subject part of the relation tuples. The bigger picture here, regarding permissions, is that we will keep all sorts of permissions here, not only apis and endpoints, but also permissions to access objects and attributes (referred to as data in our model). We'll start small, and work from there to evolve our model as needed. |
Beta Was this translation helpful? Give feedback.
Nice, that looks very good 👍
One small thing: some of your tuples (e.g.
{"namespace":"policies","object":"/system/my-api/*/rw","relation":"access","subject":"roles:/system/system-admin"}
) are not actually what you think they are. The subject is not interpreted as a subject set, but as a subject ID instead because there is no#
. But in general your tuples represent what you described 👍Regarding naming, you might want to actually have the
permissions
namespace calledapis
orendpoints
instead, but that is just from the, I assume, broken down example. It might make sense in the bigger picture that I don't see 😉Regarding the list API, it's purpose is to list the tuples exactly as they are s…