Roles vs. Permissions

Overview

Roles, groups, and permissions have been part of the Java Enterprise world for a long time. Let’s examine these concepts more closely and see which of them can be used. Roles are probably familiar to a lot of people, but they aren’t the best choice when it comes to authorization.

To demonstrate the problem with roles, consider the following example:

An example of role limitations and permissions

Our code is in production, and everything seems to be going well until we receive the message that some parts of the application are now available for employees and no longer for managers. In this case, we have to go into the code and replace the checks with a version verifying whether the current user is an employee. Another option may be to remove the checks if we want everyone to be able to perform a certain action. After that, we must rebuild our application and put it into production.

Do we risk putting it there without going through all the automated and manual tests? Think of permissions as having the key to unlocking the door to a certain functionality. All functionalities, except those which everyone is allowed to perform, need to be protected with a key: the permission. When a user logs on to the application, they get a set of permissions and keys, which allow them to open the doors to which they have been given access.

These permissions are managed outside the application, for example, in a database. When we receive the message that some functionality needs to be accessible by an employee, we have to update the store where this information is kept and assign the appropriate additional employee permission.