Role based access control
When you develop applications that are meant to be used by more than one person, you inevitably need to find a solution for managing their permissions. You usually don’t want all the users to be able to use all the aspects of your application in the same way. In this blog post, we are going to take a look at how we solve this problem in the Netgrif platform.
Roles
By default, users have no permissions and they cannot be granted permissions directly. The main reason for this is that during the design phase of process-driven application development, you cannot reference instances of application users in the model, because they are dependent on the environment the model is deployed into. Therefore a level of abstraction between users and permissions is needed to bridge this gap. Roles are this bridge.
Roles are defined in the process model and various permissions can be granted to them (such as being able to assign a specific task). Users are then granted roles, and by extension also the permissions associated with them. Any permission can be associated with more than one role. In such situations, any user that has at least one of the associated roles has the associated permission.
Let’s have a look at a simple example. Imagine that we have a process that models a loan application at a bank. Our model has three tasks: Apply, Review and Status. We want the bank clients to be able to apply for loans and the bank employees to review them. We want both of them to be able to see the current status of the loan application. We can create two roles, one for clients and one for employees, associate the client role with the Apply task, the employee role with the Review task and both of them with the Status task. This way we have achieved what we wanted.
Instance scoped roles
Have we achieved what we wanted? A role is basically just a collection of users that can have permissions associated with it. This collection is shared between all instances of a given process. This has its advantages because we wouldn’t want to assign each employee the correct role in each instance of the loan application. The disadvantage of this is that all the clients share the same role as well and would be able to perform tasks of other clients! What we need in this case is something like a role – a collection of users (or just one user in this case) – that would have different values for each instance of our process.
The answer is very simple, it is the users list data variable. Just like all other data variables, it exists in the instance scope and so can have a different value for each instance. It is a collection of users and therefore it is the same thing as a role, with the only difference being that its value can be different for each process instance.
The Netgrif platform allows us to assign permissions not only to roles (process scoped user collections) but also to users list data variables (instance scoped user collections). This allows us to model the client from our bank example, not as a role, but as an instance scoped collection of one user, that does not affect the other instances.
Negative permissions
While the clients would be happy about their loan applications, the bank manager would not. Some of his employees have figured out that if they apply for a loan, they can review it themselves! Thankfully there is a way to solve this problem as well.
A role (or a users list) can be associated with permission in two ways. One (a positive way) grants this permission to the members of the role (or users list), the other (a negative one) revokes the permission from its members. The negative association is stronger than the positive one. Therefore if the user is granted permission by at least one of their roles, but also at least one of their roles revokes the permission, they would end up permissionless, as if they never had their positive roles in the first place.
Returning back to our example and our sad manager. We can associate the Review task with the employee role in a positive way and with the client users list in a negative way. The result is that employees that apply for the loan would not be able to review their own applications, but would still be able to review applications of other clients.
The default role
The last concept that the Netgrif platform uses is the so-called Default role. It is a special role and also a property that can be enabled or disabled when modelling a Petriflow process. If this property is enabled, any task that has no roles or users lists associated with it in a positive way can be performed by any user. It behaves as if all users belong to a role (the default one) that is associated with all permissions, except for those that already have role restrictions applied to them. This is especially useful in conjunction with the negative permissions if we want to enforce an “Everybody but …” policy for some parts of our model.
In this blog post, we have introduced you to the concepts that can be used in the Netgrif platform to model various permission schemas with ease. We hope you found it enlightening and we encourage you to try these concepts out in our demo environment or to ask us any questions you might have. www.builder.netgrif.com & www.demo.netgrif.com