Role Mapping / Assignment

This article is following on from a discussion I had with Brian Stansberry to start capturing some thoughts regarding the assignment of roles to user accessing domain management.

General Three Steps

In general before an authorization decision need to take place the following three steps would happen.

1. User Authentication
2. Group Membership Loading
3. Mapping from User and Group to Roles

User Authentication

This just covers the step where the user proves they are who they say they are, after this step is complete the identity of the remote user is known and verified.

Group Membership Loading

Occasionally this could be optimised to be performed in parallel with the authentication but in general where some user repository is used the users accounts are associated with groups.  The purpose of this is that a whole set of user accounts can be assigned permissions based on this membership information rather than having to manage the capabilities of the individual accounts.

Mapping from Users and Groups to Roles

This step some form of mapping takes place to take the users identity and group membership information and assign the authenticated user to different roles.  The most simple form of a mapping could be along the lines of if user is X assign to role Y or if user is a member of group C then assign them to role D.  The group to role mapping allowing an entire group of users to be managed as one and the user to role mapping allowing for some fine tuning.

A user to role mapping does provide the option to omit the group membership loading stage although it does introduce a greater management overhead to maintain this mapping on each WildFly installation.

An even simpler mapping is where no mapping takes place - in this case the names of the groups loaded from the repository of users is assumed to be the names of the roles.  This however can cause problems as now role information needs to be represented within the user repository.

Discussing the requirements with end users at least some form of a simple mapping is required, this gives end users the ability to use groups like app1_admins and app2_admins and then for two different WildFly installations the appropriate group can be mapped to say the Administrators role for that installation.

More complex mappings could also be considered although requirements for this have not been identified yet, as an example only assigning to a role if multiple groups memberships exist for a user.

Where To Define Mapping

In general it is likely that the configuration that handles user authentication and the actual authorization checks will be split into two parts.  As it stands today for domain management we already have the security realm where we define how to access the users repository to authenticate the user and also have capabilities to load users group information.

The role mapping step could be defined against the realm.  However a realm could be used to secure access to different resources with their own sets of roles - the role mapping in the realm would then make the mapping applicable to all resources secured by that realm.  This could cause a problem with common names such as 'Administrator' where a user may be an administrator for one secured service but not another.

The second option to define the mapping is where the authorization policies are defined, this has the advantage that the roles are specific to whatever policy is being checked, this however has the opposite problem of the first approach in that different realms with different groups could be used to access the same secured service.  As an example access to the http interface could be secured with users defined in LDAP, the native interface on the other hand could use a local list of users able to use the native connection.

This also does introduce a set of considerations when we look into how to define configuration that is specific to the domain as well as configuration specific to an individual host but that will be explored in another article.