In our application we have multiple organizations The organi Ory Community #talk-keto

In our application, we have multiple organizations...

mysterious-rose-44236

10/25/2021, 1:57 PM

In our application, we have multiple organizations. The organizations have departments. Users can act on organization-level, where they have access to all the departments products - or on department-level, where they only have access to products in their own department. I'm wondering what the best way is to represent this? Currently I'm considering this approach:

Copy code

products:org=1#list@(groups:organization1#members)

products:org=1,dep=1#list@(groups:department1#members)
products:org=1,dep=2#list@(groups:department2#members)
products:org=1,dep=1#list@(products:org=1#list)
products:org=1,dep=2#list@(products:org=1#list)

groups:department1#members@john
groups:organization1#members@jane

This way, John can only list products from his own department whereas Jane can list products from both department 1 and 2. Is this best-practice, or would you recommend another approach?

mysterious-rose-44236

10/25/2021, 1:58 PM

I also considered this alternative:

Copy code

products:org=1,dep=1#list@(groups:department1#members)
products:org=1,dep=2#list@(groups:department2#members)
products:org=1,dep=1#list@(groups:organization1#members)
products:org=1,dep=2#list@(groups:organization1#members)

groups:department1#members@john
groups:organization1#members@jane

mysterious-rose-44236

10/25/2021, 2:07 PM

It's actually a bit more complex in the 'real' example: Organizations have departments and roles. Roles belong to the organization, and there is no 'department role'. A user can be a member of a certain role, but that membership can further constrained with a department, so even though members is part of the same group, their level of permissions can vary.

Copy code

products:org=1,dep=1#list@(roles:productmanagers,dep=1#member)
products:org=1,dep=1#list@(roles:productmanagers#member)

products:org=1,dep=2#list@(roles:productmanagers,dep=2#member)
products:org=1,dep=2#list@(roles:productmanagers#member)

roles:productmanagers,dep=1#member@john
roles:productmanagers#member@jane

steep-lamp-91158

10/25/2021, 6:27 PM

I think the first approach is better than the second one, as it reduces the number of direct dependencies and allows you later to change permissions inside of org1 without the need to update too much stuff at once. But all of this should be considered a workaround until we have subject-set rewrites. That would allow you to replace

Copy code

products:org=1,dep=1#list@(products:org=1#list)
products:org=1,dep=2#list@(products:org=1#list)

by a global rule that does not need any relation tuple creation over the API

steep-lamp-91158

10/25/2021, 6:32 PM

in that regard it might even make sense to not string-encode the org and dep relationship in the object, but instead represent that as individual relation-tuples

mysterious-rose-44236

10/26/2021, 7:10 AM

Thanks, Patrik - makes total sense. I just read the paper, and subject set rewrites indeed seems like the 'correct' way to solve it, I'll subscribe to the open GH Issue 😄

2 Views

Open in Slack

Previous Next