https://www.ory.sh/ logo
#talk-keto
Title
# talk-keto
m

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?
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
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
s

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
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
m

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