bored-orange-86376
04/08/2022, 4:44 PMusers
, users
have N:N relationships with accounts
and within each account can have certain role
and each role has certain permissions
.
I started modeling the above use case and came with two options:
role.admin#has_role@account1.user1
// or
role.custom_role1#has_role@account1.user1
files.delete#has_permission@role.admin
in this use case we sacrifice the ability of having user <-> account
relationship in the Keto, instead we need that on our side. On the other hand we can have generic permissions. You would then ask check account1.user1 has_permission files.delete
, i.e. the top level object would be user scoped to the account. AFAIK, in this model we wouldn't be able to use userset rewrites (or am I wrong?).
The other option would be:
account1:owner#is_member@user1
account1:files#delete@account1:owners
where one would ask check account1:files delete user1
. In this case we can also have the user <-> account
relationship in keto, we loose the ability to have generic roles shared across accounts (or am I wrong?), and we could use userset rewrites to for example give read relationship over account1:files
for anyone with delete
relationship over account1:files
.
Now, I am sorry for extensive example, I am still trying to wrap my head around the tuples model, but does the above make sense or did I completely miss something? Which approach do you think makes more sense (or is it situation specific)? Or is there better way to achieve what we want?steep-lamp-91158
bored-orange-86376
04/09/2022, 11:00 AMsteep-lamp-91158
bored-orange-86376
04/09/2022, 11:37 AMsteep-lamp-91158
bored-orange-86376
04/11/2022, 7:29 AM*
but the example:
accounts:*#transactions.refund@(roles:*:admin#member@...)
should be
accounts:{ACCOUNT_ID}#transactions.refund@(roles:{ACCOUNT_ID}:admin#member@...)
In other words, I would like to define generic tuple that would mean: Allow transactions.refund
action on account X
if the user is member of roles:X:admin
. This would allow us to define and modify the permissions for role:X:admin
role easily but the changes would apply to any account that uses this role. (best example is GCP roles where there are provisioned roles managed by google updated to reflect new permissions but one can also create a custom role).
If we created this role on account creation for all accounts and then needed to modify it that would mean millions of changes. The above example makes it one.
I think this would work with userset rewrites if we instead used:
accounts:account1#is_admin@users:user1
with
name: "accounts"
relation {
name: "transactions.refund"
userset_rewrite {
union {
child { _this() }
child { computed_userset { relation: "is_admin" } } } } }
i.e. defined generic roles via relation and custom roles via roles
object. But than there's this strange dual way of defining roles (but maybe that's the right approach).
Sorry, must be getting annoying at this point, I am still trying to make sense of it and this is where I am struggling.steep-lamp-91158
If we created this role on account creation for all accounts and then needed to modify it that would mean millions of changes. The above example makes it one.yes, exactly that is unfortunately the workaround you currently have to use but the rewrites will allow specifically also those "template" tuples
Sorry, must be getting annoying at this point, I am still trying to make sense of it and this is where I am struggling.no worries, took us a long time to understand as well 😉
bored-orange-86376
04/11/2022, 11:14 AMbut the rewrites will allow specifically also those "template" tuplesif that's the case, then that's perfect.