I have come across a scenario that needs a user to be assigned different role for each organization. When the user logs into the system, based on the organization they want to access (specified through the url or through requested scopes), I want to update scopes to limit to the permissions assigned to the role of that organization.
I have looked at “Authorization Extension” which has groups and I initially thought of using groups for each organization, but each organization cannot be assigned roles instead I need to maintain one group for each “organization-role”. The problem soon becomes a maintenance nightmare when I start updating permissions of a role, where I have to update permissions for each organization role. I have also some customization in terms of allowing users of certain organization to have access to any organization.
To make it easier and get the initial workflow working, I set the scopes for each organization on user app_metadata and based on the requested organization, I set the appropriate scopes. The problem with updating the role permissions comes back to bite in this case as well where anytime I update permissions on the role, I endup having to update all users with the role with latest set of permissions.
Ideally I would like to assign user a role for a specific organization in app_metadata of the user and at runtime pull the scopes that apply to the role and update scopes of the user in a rule. All this will become easier if I have access to the Management API from within rule.
Here are the earlier posts I’ve referred to, which are left un-answered.
I believe in that case you would be best off storing the relevant role in the app_metadata. You can then add this as a custom claim so your app can see what role the user has in their token when they attempt to interact with it. And then your rule can pick which role entry to pass on as a custom claim based on the connection or application the user is authenticating against. Manage Metadata with Rules
Are these the steps you are following? Please let me know.
Hi @lily.wisecarver, I have customized the solution a little bit so the application doesn’t have to deal with roles and instead only handles scopes. So I actually populate the scopes in the claims when generating the token. To fetch the scopes, I query the Auth0 management API using an application credentials for scopes assigned to a role.
This would have been easier if the token in the role can access more management APIs than what it currently can access so I dont have to generate the token to call the management APIs.
I have looked at some of the closed answers and I feel like they don’t quite cover this use case, so I feel it might be helpful to re-open this.
I explained the problem to the team with this example. I’ll start with the goals:
we are a SaaS platform which provides services for many different merchants - let’s call it my_saas_svc
each merchant has a unique key - we’ll call this merchantId
it is possible for a single identity to be a member of multiple merchant accounts. BUT we would like the identity to have different roles for different merchant accounts
the current proposal was to do a claims check for the merchant ID
we also have a potential use-case for customers who are also merchants
But if the identity can be associated with multiple merchantIds, this claim would need to be an array. Which leads to a few subtle security problems.
Consider this scenario, where I’m a “bad actor” trying to exploit the system
XYZ corp sells $10 Million AUD a year using my_saas_svc
I get myself hired by XYZ corp as a consultant. They assign my identity the Merchant ReadOnly role for merchant Id mer-123 using an XYZ corp email address
I use my XYZ corp email/identity to sign myself up as a new merchant. I get the Merchant Administrator role, with merchant ID mer-456
I now have roles [ "Merchant ReadOnly", "Merchant Adminstrator" ] and a merchantIds claim of [ "mer-123", "mer-456" ]
If we base our entitlements purely on the roles that are present and make no link between the role and the merchantId that role was actually supposed to be applied for, it’s a problem because it now looks like I have both roles for both merchantIds. I’m now a Merchant Administrator of XYZ Corp. In other words, if my security principle pseudo-code is:
…I’ve managed to become a “Merchant Administrator” of “XYZ Corp” as far as my entitlement checks are concerned, when I was only supposed to be a “Merchant Administrator” of the organisation I created.
What is therefore needed is a SCOPED role-assignment. This is not to be confused with “oauth” scope which has a different meaning - we’ll call our scoping “breadth” to avoid confusion. Our role-assignment would need to have a “breadth” which is limited to a specific merchant, e.g.
role assignment 1: { "role": "Merchant ReadOnly", "breadth": "my_saas_svc/merchant/mer-123" }
role assignment 2: { "role": "Merchant Administrator", "breadth": "my_saas_svc/merchant/mer-456" }
Access would be denied for my identity, since the “breadth” of the assignment for that role only covers my_saas_svc/merchant/mer-456. An example of a system that supports this kind of scoped/breadthed RBAC is Azure RBAC Steps to assign an Azure role - Azure RBAC | Microsoft Learn
I’m currently looking into “Organizations” as recommended by a colleague:
@konrad.sopala I read your comments on some of the tickets referenced here. I believe this is what those other posters were trying to explain. I also have this design issue.
EDIT: it sort of looks like organizations cover this scenario, as long as two organizations can use my_saas_svc as the IDP for both BUT have different roles between the two organizations which are put in the token on login:
It’s not 100% clear from the documentation if that’s the case, but it kind of sounds like it. I think there’s a limit on the organizations that would mean we eventually have to bump up to enterprise though. There’s some entity limits per organization per tenant as well:
Just poking this as it’s been two weeks. I’ve set a calendar reminder for every two weeks until I get a response here. I don’t really like the organizations solution since it forces the user to switch Auth0 accounts (with the login screen) to change properties. I may hand-role this as Auth0 appears to have no solution for scoped roles/permissions for people building marketplaces.