Hello all!
I have an Auth0 implementation design and scalability question that I’m hoping I can get some assistance on.
Use Case:
I’m working on a new application that will essentially be a club membership manager. The application will have multiple clubs (tenants) that can have events. Clubs will eventually be able to be public or private, but for example sake, let’s assume that any user can see in to any club, essentially as a guest with read-only permissions to public data.
Users can have multiple roles to multiple clubs. For example, a user could be the owner (admin) of one club, but then have a member role of another club. With each of these roles come specific permissions for that specific club. For a real world example, think Facebook Groups, where the user has their global Facebook account, but then can be a part of multiple groups and have specific permissions in each of those. In some groups an admin, in other groups a moderator, and in others simply a basic user.
Here’s a very basic diagram:
Creating Tenant Specific (Nested) Roles and Permissions
I’m fairly new to Auth0 and RBAC in general. And I’m wondering the best way to implement Auth0 for this use case is. I think for what are essentially nested roles/permissions for each club, I need to do something like what’s shown in the image above. So club1 could have club1:role1 and club1:role2, and each role would have their tenant specific permissions, i.e.: club1:perm1:read, club2:perm1:write, etc.
With that in mind, I have a few options I’ve come up with:
Option 1a: Programmatically generate the club-nested roles/permissions on club creation and add them to the necessary API and users as needed through the Management API. My concern with this option is scalability in the future. It would take a long time to hit the limits, but there is a possibility that I would eventually hit the entity limits for roles/permissions for the tenant.
Option 1b: Essentially 1a, but don’t use roles and assign permissions to users directly. This would avoid the limit of roles per tenant, but the assigning and managing who gets what permissions would have to be handled by my backend somewhere.
Option 2: Don’t use Authentication Core for RBAC and instead put all roles and scopes in a user’s app_metadata. The roles and permissions would be handled and defined in my database and then I would create an Action to add the permissions in the app_metadata to the token payload. This route should avoid entity limits in the distant future and I’d have to write a custom middleware on the API to check the scope, but not a big deal.
Option 3: Scorched earth, handle all RBAC in my backend and all roles and permissions, along with role-to-user mapping in my database.
Is there something simpler I’m overlooking or a better way than my options above that would also avoid the (while not likely in the short term, but possible) role entity limits? I also saw a separate service called Aserto that is supposed to integrate with Auth0 and handle scenarios like this but I’d rather not implement an additional IAM service if possible.
Thanks in advance!