6. Authorization Algorithm

This chapter describes how you can make incorporate authorizations in Dynamic Case Management in the Blueriq DCM solution.

Privileges vs. Roles

There exist multiple standard approaches to regulate your authorization needs. These can be divided in 2 categories: (1) privilege based and (2) role based.

Privileges

In a privilege-based system, every user is assigned certain privileges when signing in. These privileges can be of the form: May_Execute_Task1, Security_Level1, Can_Approve_Loans. A user can have multiple privileges. If privileges are modeled on a resource, then a user would need all those privileges in order to gain access to the resource.

Roles

In a role-based system, every user is assigned certain role when signing in. These roles can be of the form: Customer_Service, Manager, Admin. A user can have multiple roles. If roles are modeled on a resource, then a user would need one of these roles in order to gain access to the resource.

Blueriq uses a role-based system. This means that roles modeled on tasks or flows are evaluated using an OR statement. As soon as a user owns one of the roles specified on a flow or a task, he gains access to it.

Modeling Static authorization in Blueriq

Under a static authorization we understand that the same roles are always allowed to execute a task. It does not matter what the values of current attributes are in a specific case, the same roles are always authorized to execute the task. In our example scenario (1), we have modeled a task in your process, called 'Approve_Loan'.

This is the task which a knowledge worker in a bank executes to make the decision of a customer is allowed to get a loan or not. Not everybody is allowed to make this decision, and we want to indicate that only knowledge workers in the Customer_Loan department are allowed to execute this task.

You should create roles in Blueriq for every role in your organization, or for which you wish to make a distinction in the authorization mechanism. For our example, we have created the role 'Customer_Loan_Department', which will be assigned to a knowledge worker of the Customer Loan Department when he signs in.

Now you model an authorization algorithm. This algorithm decides which roles are going to be authorized on a task. In this algorithm, you can attach roles directly to your authorization algorithm. For our example, we model the 'LoanApproval' algorithm and attach the role 'Customer_Loan_Department', as can be seen above. In the case that you also want the Management to be able to approve the loans, you would also attach the Management role at the algorithm.

The last thing that you have to do is attaching the newly created algorithm to the tasks for which you want to use this kind of authorization. In our example, we would attach the 'LoanApproval' algorithm to the Approve_Loan task.

Modeling Dynamic authorization in Blueriq

So far you have learned how to create a static authorization in Blueriq. This does not suffice if your authorization is of a dynamic nature. Definition: An authorization is dynamic, if the authorised roles are dependent on values of attributes in the current case. This definition implies that knowledge workers are in some cases authorised to execute a task, and in other cases they are not authorised to do so. Please recall example (2) above, where only senior staff of the Customer_Loan Department is allowed to approve large loans.

To accomplish a dynamic authorization, most steps described above are the same. The only difference is that you check the 'Use external source' checkbox when defining the authorization Algorithm. This checkbox indicates that an external algorithm should be used to assign roles to this task. This algorithm should be implemented by a Technical Engineer, and is placed in the aquima.home/lib/ folder. You can find information on how to implement this here: APIs for authorization, routing and priority

During the design of this algorithm, the TE has access to the profile of the case, the task data, the custom field at a task to make a decision on who is authorized. For our example, he can implement the rule that if the loan is greater then 100.000, then the role 'Senior_Customer_Loan_Department' is authorized, and if the loan is smaller or equals to 100.000, then both the 'Senior_Customer_Loan_Department' as well as the 'Customer_Loan_Department' is authorized to execute this task.

Logging in with roles

At the start of the application, a user should log in with a username and password, and get the roles assigned which he fulfills. This can be done in Blueriq in two ways. (1) Using the user.properties file, and (2) using an LDAP connection.

When opening the user.properties file in the aquima.home folder, you can define the users, their passwords, and their assigned roles as can be seen on the left.

When connecting to an LDAP, Blueriq receives a list of roles of the user logged in. In our default mechanism, these roles are matched with 'Authorization Roles in studio, which are different to the 'Roles' which we have described so far in this tutorial. As can be seen on the left, an authorization role is a group of roles. In this example, if a knowledge worker is logging in with LDAP, and LDAP assigns 'Loan_Department' to him, he will get two roles assigned to him: 'Customer_Loan_Department' and 'Employee'.

An alternative method is to skip the authorization roles, and directly match roles with the LDAP connection. This can be done with a custom implementation of the LDAP connection by a project. Please note that the LDAP should then assign 'Customer_Loan_Department' and 'Employee' to a user to get the same effect compared to the use of authorization roles (where LDAP only assigns 'Loan_Department'.