https://authzed.com logo
Join DiscordCommunities
Powered by
Hi, looking for some help with schema
# spicedb
j
Hi, looking for some help with schema design. To distill to the minimal problem, I have users and resources, and want users to be able to share access to individual resources - that is, not allow the grantee to gain /all/ of their permissions, but only their rights on a specific resource. I also want to keep track of the provenance of the grant, rather than cloning - for instance, if user A grants resource 1 to user B, and user A later loses access to resource 1, then user B should also lose access to it automatically. I have an approach that /almost/ works using a pseudo-object to represent the grants themselves, but am running into difficulty. Continuing in thread.
Here's the closest I've gotten: definition user {} definition resource { relation owner: user relation accessible_via: grant permission can_use: owner + accessible_via->can_use } // Grant IDs should be of the form: // {grantor}\_{grantee}\_{resource} // // 1. A user owns a resource and wants to share it. Say that resource 1 is // owned by user A, who wants to share it with user B. // * Add a relationship 'accessible_via' from resource 1 to grant A_B_1 // * Add a relationship 'granted_to' from grant A_B_1 to user B. // // 2. A user has access to a resource via grant, and wants to share that // access with another user. Say that user B from above now wants to share // resource 1 with user C. // * Add a relationship 'granted_to' from grant B_C_1 to user C. // * Add a relationship 'delegated_to' from grant A_B_1 to grant B_C_1. // // If user A later revokes access from user B (by removing the // 'accessible_via' relation from resource 1 to grant A_B_1), then user C // will automatically become unable to use resource 1. definition grant { relation granted_to: user relation delegated_to: grant permission can_use: granted_to + delegated_to->can_use } The problem here is with diamonds. I realized I don't really want the chain to be in the "grants" space, because I want a grant to remain valid if the grantor has access through any mechanism - that is, in the example, if A\_B_1 is revoked, but user B still has access to the resource in some other way, then B\_C\_1 should remain valid.
Similarly, I considered naming the grants simply by the grantee - so the grants would be B_1 and C_1 - but then had the inverse problem, where having C_1 depend on "all the grants that are granted to B" felt backwards.
Wondering if there's a better pattern for this - I haven't been able to find anything directly comparable on SO or the blog
y
what you're doing is definitely how i'd approach the problem naively
i suppose there also might be an approach where you walk through a user, but that might get hairy with potential cycles
> then B_C_1 should remain valid i'm not following how this becomes invalid if 
a_b_1
is revoked
can you share a playground that has some test relations and assertions?
j
Here's my playground: https://play.authzed.com/s/yCQWAmHZ_4L3 The examples are: * r1 - basic case, Alice has granted to Bob who delegates to Charlie * brokenchain - Alice previously granted to Bob who then delegated to Charlie; then, Alice revoked from Bob (by deleting the accessible_via relationship) Those two are working fine. The tricky case is 
diamond
. Alice granted to Bob and Charlie, both of whom delegated independently to David. David then delegates to Ellie. As I have it written, he specifically delegated the grant that he got from Bob... but he could equally as well have delegated the grant that he got from Charlie instead. Ideally what should happen is that if Bob revokes from David (by removing 
grant:alice_bob_diamond#delegated_to@grant:bob_david_diamond
), David and Ellie should both still have access (via Charlie).
I think I'm realizing I've overcomplicated this, though. If the grants represent the nodes in the graph (
bob_diamond
and 
david_diamond
) rather than the edges, then this problem disappears... not sure why I didn't spot that before https://play.authzed.com/s/wSUf-1epQTWA
y
ohhh sure. the subtlety of SpiceDB storing edges rather than nodes is something that tripped me up when i first started learning the schema language, and making that shift helped a lot.
PreviousNext
Powered by