The traditional access control model used in many systems is based on objects and lists that control access to these objects (ACLs). In short, each object (for example, a file or directory in the file system) has a list associated with it that grants certain types of permissions (read, edit, delete) to users or groups of users recognized by the system. In this model, the administrator needs to “translate” the organization’s authorization policy for the permissions (ACLs) that can be attributed to objects. This model is perfectly acceptable under most circumstances. However, certain applications have business rules requiring a more complex authorization model.
In this case, an alternative for controlling access is the RBAC (role-based access control) model, which grants permissions in the application based on the roles exercised by users or groups of users in the organization. Thus, a role in the RBAC model is associated with a real-world function or position (for example, a finance manager). ACLs are no longer associated with objects, but rather the set of permissions that must be granted so that the specific functions of the real world can be exercised in the application by those responsible for these functions are determined. In other words, in the RBAC model, permissions that represent application functionalities are attributed in advance to roles, and application users (or groups of users) are associated with these roles and automatically inherit the associated permissions (see figure below).
One issue with the RBAC model is that permissions attributed to a role (finance manager, administrator, auditor, etc.) are transferred to all users associated with a role without any additional contextualization. Although this is not a serious limitation for many applications, for the system this approach is unsatisfactory, since quite often you want to grant permissions to certain users only as long as they have a certain relationship with an object. When this relationship is terminated, the permission should no longer be granted.
For example, when we say that the leader of a compliance project should be able to close the project, we don’t mean that the leader should have permission to close any project, but only the project for which the user is leader. There is then a context or additional condition here that must be checked before the permission is granted.
Given these considerations, the system requires a variation of the traditional RBAC model is required, which can be classified as an extended role-based model.
This model grants permissions to privileges directly through the inclusion of people (or groups) in profiles, which in this way will act as the traditional RBAC roles as shown in the illustration below, people (or groups) included in profiles inherit permissions to privileges granted previously to these profiles.
This model can also grant conditional permissions to people (or groups) that have been assigned to perform certain roles in the system, such as when they are assigned as perimeter manager or project leader. In these cases, permission will always be conditional on a contextual evaluation (allow… if…).
The figure below illustrates the extended RBAC model adopted in the system. It can be compared with the figure below, which illustrates the traditional RBAC model.
Managing permissions in the system is greatly facilitated with this role-based model. If access control were based on ACLs (access control lists), system administrators would need to determine permissions for each user for each object. In environments with many users, this would require a great deal of work and be prone to errors. On the other hand, in the extended role-based model implemented in the system, this task becomes much simpler since the settings for permissions to be granted in the various system privileges (operations) for the profiles and roles are established by default with the system installation, so that the administrator only needs to include people (or groups) in the different profiles and assign them to roles so that they can automatically inherit the permissions. Note that the default permissions granted to profiles and roles can be edited at any time.