FusionAuth implementation design suggestions

amar.sibia

Hi All,

I'm looking to implement RBAC with FusionAuth on a new project. We have a need to manage 3 levels of permissions.

User Access (granular permission claims)
User Position (user type, would be good to be able to allocate access claims to Position types)
User Teams (collection users that work together)

I have a couple of approaches I have been evaluating, my preference would be a solution where all 3 could managed within FusionAuth. However, I only see 2 manageable pieces to play with, Roles and Groups. Currently, if I want everything to be managed within FusionAuth, I believe my only option would be to use Roles within FA to represent User Positions, and Groups to represent User Teams. This would mean loosing the granular controls we would like to implement.

Hopefully someone could help point me to an implementation that would allow us to manage all 3 aspects within FusionAuth

mgetka

I would consider defining both positions and teams as groups. With such approach one user could have multiple positions - if it is an issue, you would need implement such restriction in your application.

Later on, you define set of granular permissions as roles. The user can obtain a permission (role) in two ways:

explicitly - the user has specific role set,
implicitly - the user is in a group (position/team) associated with the role.

dan

I think @mgetka makes some good points. I'm afraid I don't have enough detail to provide an authoritative answer. From what you've said, I think you could do this with roles, application registrations, groups or even user actions. You could for example, have three different groups of roles (they are just strings, and you can add more than one to a user):

...
team1_member
team2_member
...
position1_holder
position2_holder
...
access_perm_1
access_perm_2
...

I guess it also depends on how you want to consume these. Are you going to be looking up the user via FusionAuth API calls? Or will you want this embedded in a JWT for portable claims?

In the former case (API calls) you can make multiple calls and learn a lot about the user.

In the latter case, even though you have the JWT populate lambda, it is limited to what is on the user and registration objects.

So you couldn't, for example, know the group name (though I believe you have the group id) in the lambda, so you couldn't put it in the JWT. More on this issue.