https://authzed.com logo
Join Discord
Powered by
likely the caveats feature
# spicedb
y
likely the caveats feature
i
Hi @yetitwo , thanks. I had looked at the caveats feature, but that seemed to be intended more for conditional relationships, than actually passing in brand new relations. Do you have an example you might be able to share? I found this article, but it's not quite what we need: https://authzed.com/blog/top-three-caveat-use-cases
y
it wouldn't be represented as a temporary relation - you'd need to rephrase your request in terms of the caveats feature
in spicedb, if you have request-time information that you want to provide, you do it with caveats
i
Ok. I'll try to think through how that could work. At first glance, it seems like we'd need to duplicate our auth logic, one eval path for users managed via relations on groups in SpiceDB, and another evaluation path (probably with the union "|" operator) that says if their context has a specific group?
y
i'm not sure off the top of my head - caveats are one feature i haven't dug into
j
if a user has access without condition, writing them directly
if they have conditional access, write the relationship with a caveat
i
Hi Joey, can you explain more? As I understand it, the user's access would not be conditional, they would be a part of their groups present in their token. The difference is I just need to pass in those relationships during the evaluation, since my application won't know about them before receiving the token
j
does the token say they are part of a group or is it something other indication?
i
Yeah, generally with some of the enterprise IDP's we integrate with, they have a claim in the token that is similar to:
Copy code
"groups": ["group1", "group2"]
So generally, it says they are members of a group or role
j
and how would these groups impact the authz decisions?
how do they link over?
i
They would correspond to a 
member
relation on a 
group
resource in our authorization model. Then permissions would be determined from the groups relation with other resources. You could think of it as well in terms of roles, the claims in the token would represent the roles that have been assigned to the user from the external IDP, so those roles would then have relations with other objects.
j
right, but to... what? if the membership of the groups is not contained in SpiceDB, what are you linking to? is it the resource->group?
i
I'm not sure I understand your question but let me give an example to see: One of our resources is a 
project
, and project would have a relation 
owner: group#member
, and permissions would apply to the project resouce based on the members of the 
owner
group.
j
okay, so it is resource->group
i
Yup, it would be resource->group, then group->user, but the group->user comes from the IdP's token. OpenFGA supports this by passing in evaluation-time relationships that are not persisted in the relationship DB. I'm trying to understand what might be a way in SpiceDB to support this workflow
j
you'd write a caveat on the member to 
user:*
and check the group ID
like
Copy code
caveat has_matching_group_id(group_id string, users_group_ids list<string>) {
  users_group_ids.contains(group_id)
}

definition group {
  relation member: user:* with has_matching_group_id
}
then write a relationship 
group:whatever#member@user:*[has_matching_group_id:{"group_id": "whatever"}]
something like that
eval-time relationships are "easier", but they would have a negative caching impact
we've been investigating what it would look like to support it without destroying caching
but nothing concrete on that yet
i
Ok I think I'm understanding now. So this effectively says "make any user a member of group whatever, but only those that have a matching group ID in their context at eval time can use the relationship"?
j
basically
you could also just not have the 
group
itself
and instead do
Copy code
caveat has_matching_group_id(allowed_group_ids list<string>, users_group_ids list<string>) {
  // ensure the groups have crossover
}

definition project {
  relation viewer: user:* with has_matching_group_id
}
err, sorry; 
project
I forget the exact function name for intersection of lists
that would likely be more efficient, if a bit less nice to manage
i
Ok that makes sense. Thank you very much for the examples Joey!
94 Views
PreviousNext
Powered by