https://authzed.com logo
Join Discord
Powered by
is it necessary to write relationship
# spicedb
o
is it necessary to write relationship and attach caveat to it while writing relationship? For eg i have written a caveat which verifies whether given userId is from list of userIds provided do i have to write relationship and create userId and attach caveat to it?
v
you don't have to. You can provide all caveat arguments at request time
you only need to specify that the relationship written has a caveat, so you set the caveat name, but you can leave the caveat context empty
o
ok but i am unable to verify in playground
definition user {} definition service{} definition partner{} definition org{ relation audit: user permission all = audit } caveat above_hierarchy_user_ids(user_id string, valid_user_ids list) { valid_user_ids.exists_one(r, r==user_id) } definition document { relation partner: partner relation service_read: service relation service_write: service relation created_by: user relation doc_org: org relation read: user | user with above_hierarchy_user_ids relation write: user permission reader_permission = created_by+ read + write + doc_org -> all + service_read + partner permission writer_permission = created_by + write + doc_org -> all + service_write + partner }
-------------------------------following is my assertion in playground
assertTrue: - 'document:1#reader_permission@user:123 with {"user_id": "1234", "valid_user_ids": ["1234", "6782"]}'
v
@origami5356 I got it to work, see https://play.authzed.com/s/Z9P1u8WbdoZp/assertions
other than missing the relationship that has to be written, I don't see anything else wrong in what you posted
o
yeah, that was my question do we have to write the relationship? in ABAC it takes all the attributes and runs policy check over them, here why we have to write relationship with explicit userId ?
do we have to mandatorily create relata ionship with some userId?
v
this is by design, SpiceDB does not support request-provided relationships, only caveat context can be provided at request time. It's a design choice, systems that do contextual relationships won't scale according to the Zanzibar paper design.
So the recommended way to model this with SpiceDB is to write explicitly the users that have been granted access to the resource. Caveats, as the name indicate, is a way to modify that permission with contextual data.
o
we have a use case where we have hierarchy of users e.g ClusterManager->Manager->salesPerson->helper H1 / SP1 / M1 / CM1 \ M2 \ SP2 \ H2 here we want resources created by salesPerson should be accessed by him or users above hierarchy e.g Document created by SP1 can be accessed by M1 or CM1 not by M2 This hierarchy keeps changing so i don't want to store this in relationship so how can i model this
v
This can be modelled easily with SpiceDB:
Copy code
definition user {
    relation managed_by: user

    permission manager = managed_by + managed_by->manager
}

definition resource {
    relation creator: user

    permission view = creator + creator->manager
}
}
You can create any arbitrary hierarchy of users in runtime by writting the relationships between the users, and then specify that a user has permission to a resource if it's the creator of the resource, or a direct or indirect manager
o
oh I forgot to mention that this hierarchy is controlled by some other service
v
That other service can still write the relationships with the corresponding hierarchy
y
you generally need to add relationships to SpiceDB in order for SpiceDB to do its job. it's not going to work to only hold that information in your primary datastore.
o
this was helpful. But in this if I want to access resources created by the user himself or users below his hierarchy how can I model this?
v
so you want to reverse the permission hierarchy, instead of "user that created the resource and anyone above in their management chain" you now want "user that created it and anyone below their management chain"?
o
yes
y
you create relations in that direction
o
@yetitwo that's bad design know, if i want both i.e only those user can access who are above the hierarchy and only those user who can access who are below the hierarchy so I have to maintain both direction relationship.
@vroldanbet you posted about "user that created the resource and anyone above in their management chain" i am concerned about "user that created it and anyone below their management chain"? without duplicating the relationship
y
why is that bad design? if you don't need the other direction, just use the direction that you need
and if you need both directions because of the questions you need to ask that's not a bad thing
o
i feel there is duplicate of data. I am just thinking if we could have Written relationship once (who is manager of whom) and traverse both to tthe op and to bottom other wise i think we have to do something like this. Correct me if i am wrong
definition user { relation managed_by: user relation user_under: user permission top_manage = managed_by + managed_by->top_manage permission bottom_manage = user_under + user_under->bottom_manage } definition lead { relation created_by: user permission edit = created_by + created_by->bottom_manage permission view = edit } Relation: user:ashish#managed_by@user:kamal user:kamal#managed_by@user:saurabh user:saurabh#user_under@user:kamal user:kamal#user_under@user:ashish user:ashish#user_under@user:kartikey lead:1#created_by@user:ashish
v
if there is duplicate that's fine. Just make sure to model the graph in a way that supports your authorization logic
SpiceDB allows you to transactionally write those duplicate relationships if needed
and yes, that design you posted seems mostly fine to me. You have to defined who are the managers, and who are the reports
It would look like this. Just make sure you don't create a loop.
Copy code
definition user {
    relation managed_by: user
    relation reports: user

    permission manager = managed_by + managed_by->manager
    permission manages = reports + reports->manages
}

definition resource {
    relation creator: user

    permission view = creator + creator->manager + creator->manages
}
and I don't see any duplication here, you are cannonically defining who they are managed by and who are the user reports
3 Views
PreviousNext
Powered by