Hi playing around a bit with the examples, here is...
# talk-keto
l
Hi playing around a bit with the examples, here is my setup:
Copy code
# User1 owns usergroup:
echo "usergroups:395ba5f9-f596-4095-aaf1-25d138dfab9c#owner@(users:72f65406-45b1-4b2a-a6f2-af909c10c832#)" | \
  keto relation-tuple parse - --format json | jq . > ./relation-tuples/user_usergroup.json
Copy code
# Usergroup owns location:
echo "locations:0a4fa775-1bed-455b-b1b1-b91d40df667b#owner@(usergroups:395ba5f9-f596-4095-aaf1-25d138dfab9c#)" | \
  keto relation-tuple parse - --format json | jq . > ./relation-tuples/usergroup_location.json
I would then think that I can validate the first authz relation like:
Copy code
keto check users:72f65406-45b1-4b2a-a6f2-af909c10c832 owner usergroups 395ba5f9-f596-4095-aaf1-25d138dfab9c
It fails, since the user is not a subject, removing the
#
makes it work. would it be possible to evaluate locations the same way? Yupp:
Copy code
keto check users:72f65406-45b1-4b2a-a6f2-af909c10c832 owner locations 0a4fa775-1bed-455b-b1b1-b91d40df667b
2
s
Please note that subject IDs do not have a namespace. If you add the
users:
prefix, it is just part of the subject id string I.e.
users:12345
is not equal to
users:12345#
and not equal to the subject id
12345
1
c
on that note, what would be a canonical way of recording a direct relation between an object and a subject that itself belongs to a namespace (for example groups, as opposed to the one where the subject is not a namespace, such as e.g. concrete users)?
👀 1
• specifying only the subject id can lead to conflicts, since group uuid may match the user uuid • OTOH, specifying the namespace in the subject usually means denoting a subject set, which is not the desired outcome
so it looks like the optimal solution would be to prepend the namespace to the subject id (e.g. pass
groups:123
as a subject id during read/write), which feels a bit hacky
s
how you represent IDs is up to you, if your usecase needs a prefix to ensure there are no clashes of IDs than that is totally valid
but prefixing is the better option than having a subject set
c
got it, thanks!
s
if you have a tuple with
groups:1234#member@1234
, the IDs are still not considered equal btw, one is an object ID in the groups namespace, while the other is a subject ID
c
yup, that’s clear, was wondering more about making sure I can represent both
box:42#owner@1234
and
box:42#owner@groups:1234
at the same time without conflicts, where subject id
1234
refers to a particular user (without a
users
Keto namespace) and subject id
groups:1234
refers to a particular group (where
groups
is a Keto namespace)