Users: Role Based Security

Role Based Security

Users in the system have a single Role. A Role is a set of Permissions. The relationship between Roles and Permissions is many to many, thus one Permission may exist in multiple Roles.

Most services require a Permission in order to be invoked through their REST interface. If the caller has the necessary Permission then the security framework will invoke the services operation. This still allows the operation to perform additional checks if needed in order to filter data or restrict access based on some state in the application that cannot be expressed statically in the declaration of the service.

Permission Granularity

Services typically have their own Permissions. By convention, these permissions are separated into service operations that read data and those that modify data. This should be sufficient for our initial needs. If not, a more granular approach that incorporates additional verbs or perhaps an ACL could be implemented (Spring Security ACL for example).

The naming convention for Permissions is PERM_READ_ and PERM_MODIFY_. These prefixes are applied to the permissions that govern read and modify operations in order to make the security annotations easier to read. There's no special handling of the permissions based on their name, this is just for convenience.

PreAuthorize annotation

Spring Security's PreAuthorize annotation is added to the service interface operations along with an expression that must be satisfied in order for the operation to be invoked. The security framework will invoke these expressions for us and avoid invoking the operation unless the expression is satisfied.

In cases where we need security, we'll use the hasRole expression within the annotation. For example, the check for adding a new Compound into the system might look something like:

@POST
@Path("/{id}")
@PreAuthorize("hasRole('PERM_MODIFY_COMPOUNDS')")
Compound update(@PathParam("id") Long id, Compound compound);

Mapping Permissions to Spring Security

It may seem odd that the PreAuthorize check in the above example uses a function called hasRole in order to determine if the caller has the required Permission. It's even stranger when you consider that Spring Security has a function named hasPermission. This is an unfortunate collision of names/concepts.

• Our system models entitlements with Roles and Permissions.
• Spring models entitlements with a User and GrantedAuthorities
• the hasRole() call in the PreAuthorize annotation checks to see if the User has a GrantedAuthority with the given name
• Our custom login code for Spring Security creates a Spring User and adds one GrantedAuthority for each Permission in the Role that our Domain User is in