On the roles and permissions recipie, is there support for associating roles with another object? For example, on our system users belong to a number of teams, and have a role within that team so the same roles and permissions need to be duplicated for each team. Is there a way to support that within the recipe or would I have to build it entirely separately?

hey @PitchAsh you can associate roles with any random ID - it doesn't have to be the user ID.

So if we have roles, "admin, member, guest" and 1000 teams, we would need 3000 different roles?

not really. You can associate those roles with the teamIds directly.

how do i make user A an admin on one team and a member of another?

so instead of mapping users to roles directly, you can map a string like

"<userid>-<teamid>"

role

roles get aissnged to a user though right?

not necessarily. you can assign them to any unique ID

so wouldnt we need "-" so.. the 3000 roles i mentioned and I then assign "teamA-admin" and "teamB-member" roles to user A ?

the number of roles is still just 3. But the number of role mappings are 3000

ok.. so how do I add this users roles to the session if its "-" ? I would have to iterate over and make multiple calls for every team?

so you want to override the getRoles function in the user roles recipe. This function takes in a userID. Now you can pass in the current teamId to it as well (using userContext), and then call the original impl with the

<userid>-<teamid>

string

ok that works in the case where we have a selected team..

oh yea. If you want to get a union of all of them, then you would need to query all (based on the current approach)

probably easier to just do all the rbac locally in this case

Hmmm. Fair enough. How could we have made this simpler for you? What’s the missing “data structure” in our case?

if we had second dimension on the role it would work

I see. Makes sense! Thanks

Is this something that might get added?

Not sure yet. We have a LOT of other features already in our roadmap. So not anytime soon anyway.

Ok thanks.. Maybe ill work with 3 roles and the permissions in supertokens and maintain the userId + team -> role mapping my side

So if you want to reuse our pre built session claims (UserRolesClaim and PermissionsClaim), then you should override the recipe function from the user roles recipe - since our claims use those functions as the source of their info. If you want to build your own session claim and validator, check this doc out: https://supertokens.com/docs/session/common-customizations/sessions/claims/claim-validators

Im struggling to understand why we would use the more complex claim validator methods rather than the simpler mergeIntoAccessTokenPayload method..

well, you could just use

mergeIntoAccessTokenPayload

as well.

doesnt mergeIntoAccessTokenPayload refresh to the frontend immediatly?

yea it does (if called on the session object). But if you update the roles offline, then it won't update the session unless you call mergeIntoAccessTokenPayload on that session as well

ok.. so the claim validator means that if a super user changes anoter users roles / permissions.. then it will refresh for that user without us having to check and potentially call mergeIntoAccessTokenPayload on every api endpoint..

correct. Depending on how the claim validators are used in the APIs (they have a maxAgeInSeconds config)

ok so a claim validator seems like the way forwasrd.. what i need to do i think is expand the roles claim into a 2 dimensional array..

Right.

if a permission is added to a role does this reflect onto any logged in users? at some point the claim will refresh and the new permission will be there?

> at some point the claim will refresh and the new permission will be there? Correct. You can force refreshing of permissions / claim on certain "sensitive" APIs by setting a very log maxAgeInSeconds when using the claim validator functions.