https://authzed.com logo
Join Discord
Powered by
ohhhh 🤦‍♂️ yes, that makes total sense. the inte...
# spicedb
y
ohhhh 🤦‍♂️ yes, that makes total sense. the intent is to have user personas which grant access to some subset of the application's features by granting some subset of a user's permissions (e.g. the user is wearing their admin hat today vs trying to replicate something that a less-privileged user is seeing). there's a debate to be had about whether this is an authorization concern, but we were hoping to be able to implement it at the authorization level and that it wouldn't be too difficult. is there a better way to model that kind of idea, especially in this iamish schema? (iamish referring to the google cloud IAM blog post) I can see that it should work if I go and add a persona relation on the role as well, but that seems kludgy.
c
Are users of your application creating and defining their own roles or is there a static set of permissions?
y
currently it's a static set of permissions, but the intent is to make this self-service in the future, which would require something closer to this approach
and i like the way that the iamish approach separates the "what can a user do" from the "on which objects can the user do it"
I suppose we could treat personas as "just another user" for the purposes of the authorization model, though that muddies other things
I suppose for the purposes of modeling the persona and user are equivalent 🤔
c
It seems like a user is temporarily assuming another role, correct?
y
more or less - the idea is that there would be roles attached to personas as well as users, but those persona roles would be a strict subset of the user roles
i'm looking at the Google Cloud IAM blog post and there's this bit: > First let’s start with the role itself. We’re going to enumerate all of the possible permissions that can be held by the role. We’re also going to set the subject type for adding a permission to a role to 
user:*
. This will allow us to express the concept: “any user who holds this role will have this permission”. How is this actually used/computed? Like in the role binding where it's:
Copy code
permission blah = user & role->blah
what makes the 
user:*
bit on the role important for that computation other than that the relation exists? what explicitly ties it back to the user, and what about that prevents you from using another subject in that computation?
e
if 
role->blah
is 
user:*
then 
user & user:* == user
, i.e. the intersection of one user with all users is just the one user if 
role->blah
is not 
user:*
(the role doesn't grant that permission), then 
user & [empty] == [empty]
, i.e. the intersection of one user with no users is no users if 
user
is not set, then the rolebinding isn't bound to a user, and the intersection will be empty even if the role binds to 
user:*
(I'm going based off your example here, I don't have the blog post open to compare, sorry if I contradicted the schema in some way)
y
oh, no, that does make sense. i didn't understand that the intersection behaved that way - I was assuming it was more like a logical AND between two permissions/relations. it sounds like the reason this fails is that the set of a single persona relation intersected with the set of all relations on users is empty, because the sets of personas and users don't overlap.
2 Views
PreviousNext
Powered by