Users, Roles, Permissions - Best Practices

alan.wood

I've read the various documents and have a few questions about how to deal with more advanced scenarios.

I have a set of organizations that have multiple "products". I also have a set of micro-services that coordinate together to produce those "products". Within that product, some of the micro-services are likely coordinating to produce "tools". That results in the following hierarchy:

Organization
- Product Suite
  - UX Tool / API
    - Microservice

My goal would be to have a single sign on for the entire organization, so that all products are signed into. Users have different roles for all the various tools, and those are what the users would primarily be logging into.

Therefore, I've mapped:

Hierarchy	Fusion Auth
Organization	Tenant
Product	no mapping
Tool/API	Application
Micro-Service	no-mapping

For "general" roles (admin, user, etc.) and allowing a user to use a tool/api the user would have a registration record for the particular tool/api and a set of roles assigned to them.

I don't see a way to manage "permissions" in fusion auth (what a role would allow a user to do) - so I assume that concept would be left to the individual micro-services to handle.

I also have a new requirement and I'm not sure how to map that in fusion auth. I've looked into Entities - but am very confused by them and not sure if they are meant for this use case or not. That requirement is that a particular user may have different roles in the same tool/api based on the "context" they are trying to work with.

For instance, we could have multiple "customers" in the tool and some users would have different permissions sets based on which customer they are looking at. (For instance, a user would have no access to some customers, management roles/capabilities of a subset of the customers and read only visibility on others).

First question is if my "mapping" follows the best practices for fusion auth. I want to make sure that I don't map in a way that means I'll be fighting with the solution.
Second quesiton is, how would the community suggest that we model the new requirement in fusion auth, or is the capabilities of fusion auth not a good fit for this use case?

Thanks!

joshua

It would appear that you are requesting functionality similar to scopes in OAuth:

https://github.com/FusionAuth/fusionauth-issues/issues/218
https://github.com/FusionAuth/fusionauth-issues/issues/275

Please upvote these issues if they apply to your use case.

I don't see a way to manage "permissions" in fusion auth (what a role would allow a user to do) - so I assume that concept would be left to the individual micro-services to handle.

I believe that you are correct. You would have to write this integration code.

Roles can be used. They are entirely free form. Meaning you can assign the role of "monster_maker_person" to a user and define what the role can and cannot do at the integration code level.

A few other customers have unique implementations regarding roles and permissions. You can read more (at a high level) about them below.
https://fusionauth.io/blog/2021/06/15/sunfinity-fusionauth-python/#undefined

First question is if my "mapping" follows the best practices for fusion auth. I want to make sure that I don't map in a way that means I'll be fighting with the solution.

The answer to this question might be in the details of the integration. From afar, it seems reasonable to me. We do offer professional services/contracts should you need additional support in your integration.

Second quesiton is, how would the community suggest that we model the new requirement in fusion auth, or is the capabilities of fusion auth not a good fit for this use case?

After browsing our open issues (https://github.com/FusionAuth), feel free to log your own use case if not covered.

I hope this helps!

Thanks,
Josh