https://authzed.com logo
ohhhh 🤦♂ yes that makes total sense
y

yetitwo

03/14/2023, 8:18 PM
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

corkrean

03/14/2023, 8:29 PM
Are users of your application creating and defining their own roles or is there a static set of permissions?
y

yetitwo

03/14/2023, 8:31 PM
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

corkrean

03/14/2023, 9:29 PM
It seems like a user is temporarily assuming another role, correct?
y

yetitwo

03/14/2023, 10:06 PM
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:
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

ecordell

03/16/2023, 2:07 PM
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

yetitwo

03/16/2023, 2:31 PM
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.