Case Security
From Business Process Management, BPM and Workflow Automation Wiki | BizAgi BPMS
<keywords content="keywords"> security, private, closed cases, sharing information, shared information, public information, private information, allow access, restrict access, to cases </keywords>
Contents |
Case Security
There are companies in which the management of information is a very sensitive issue that requires special control to limit the data exposure. That is why it is necessary to define the authorization to access information through the Work Portal, indicating which users have permissions over a case and which are unauthorized to see privileged information.
In a scenario without customization of security, anyone can find a case and in the results table access all the related information. However, this information may be confidential and would need to be restricted to some users who might see it and study it.
According to the needs of each project there are two types of users that can be defined in Bizagi for a case: - Users without privileges: they cannot see any information on the case. - Users with privileges: they can see all the information of a case.
Privileged users will be:
- Those who have worked on the case
- The creator of the case.
- Users who have been assigned. The allocation method Everyone will automatically include all users that can take a case.
- Users added through an expression granting them privileges
Security must be defined at the process level from the Modules view. Processes can have one of three possible security levels that will be applied to each cases created.
- Public: Anyone can search and view all your information.
- Private: only privileged users have access to the case’s information.
- As parent (applies to sub-processes): security will be shared between parent process and child process (or sub-process). If the parent process has Private security all users who have privileges on the parent process may access the child's information and vice versa. If the parent process has Public security, all cases of parent and child processes can be seen by all users.
If the sub-process has As Parent security and it can be created independently, its cases will be private.
Private Case security
As Parent security
Delegated users can see cases that are assigned to them in their Pending list. But if they are NOT part of the privileged users they will not be able to search and find the case through the query engine.
Case security scenarios
In the Work Portal it is possible to access case from several places: 1. Search by case number or by Search option
4. Queries
5. Pending list
For the first four scenarios the Case Security will apply. That is, if a user is part of privileged users he/she will have access to the case’s information accessed by any of these places. The Pending list does not have Case Security. If a user is assigned a case or it has been delegated, the case will always appear in the Pending list and it can be accessed along with all its information.
Security must be defined in the development environment of a project. It cannot be configured in production because security is tied to the life of each case. Therefore it cannot be included in the middle of an existing case. If you need to make changes to the case security in the Production environment, you should be make the required changes in the development environment and then make a deployment.
Business Administrator or Super user
Case Security has a role that is available to be included to any user called BA Business Administrator. Any user who has this role will be able to find any case without restrictions. That is, the user who has it will always be Privileged in all processes
Expressions to allow or restrict access
Bizagi provides a set of functions to add or remove users from the Privileged users list of open cases using an Expression.
The functions allow to:
- Add a User
- Add a user list
- Remove a user
- Remove a user list
Case Security Functions
- CHelper.GrantCaseAccess (int idCase, int idUser): adds the user to the list of privileged users
- CHelper.GrantCaseAccessToUsers (int idCase, Arry Users): adds multiple users to the list of privileged
- CHelper.RevokeCaseAccess (int idCase, int idUser): Removes a user from the list of privileged users
- CHelper.RevokeCaseAccessToUsers (int idCase, Array Users): Removes multiple users of the list of privileged users
These functions use two parameters: the unique case identifier and users identifier. When the function receives only one user the user’s identifier must be entered. When it receives multiple users an array of user identifiers is required. The identifiers are integers that are automatically created in Bizagi and are unique for each record. Therefore, each case has its unique identifier, as each user does. NEVER AND UNDER NO CIRCUMSTANCES type the integer or the identifier number in the expression leaving it fixed. To get the ids Bizagi provides a number of methods to consult. For example, the method CHelper.getUsersForRole (int idRole) returns an array of user ids belonging to a particular role.
To get cases identifiers we reccomend these functions:
- Me.Case.Id, returns the case id for the current case.
- CHelper.getSiblingProcessesId (Me, iWfClassId): returns an array of sub-processes case’s ids, that are all created from the current sub-process’ parent process.
- CHelper.getSubProcessesId (Me): returns an array of case’s ids, that are all sub-processes of the current parent process.
For more information on the functions of obtaining user IDs and cases ids visit CHelper
Example of Case security using expressions
In a Purchase Request process the information must be restricted so that the creator and he/her boss can access its information. According to what was explained above, all users who are assigned during the case will also have access. The user creator, by definition, will automatically be added to the list of privileged users. However, the user’s boss must be added through an expression so he/she can have access to the case from the beginning. To achieve this you must set the process to have Private case security. Then add an expression that includes the user´s boss as a privileged user. 1. From the Modules view access the process properties right clicking on the active version.
2. Choose the option Private to restrict the access to the cases information for all users except privileged ones. Then click OK.
3. In step 4 (four) of the Process Wizard, go to Activity Actions to create an expression. Select the action to be On enter. The rule should add to the list of privileged users to the creator’s boss.
In the next video you will see how the above example works. There are three users. The first one called CreatorUser will be the one who creates the case. The second user will be the boss, called Boss. Finally a user called RestrictedUser must be restricted. The user who creates the case is automatically included as a privileged user. We have previously configured the Boss user to be the Creator’s boss. An additional user named RestrictedUSer will not be able to see or find the case created by the user Creator.
<videoflash>4lrco0126oU|640|505|</videoflash>
Case security with sub-processes
Sub-processes can be created with As Parent security so that users who have privileges on the parent process will also have them on the child process (sub-process) and vice versa. In the Purchase Request process used previously, once the boss approves the request a new sub-process is created, called Quotations. The person responsible for making quotations, a user called Quotations will be assigned. Since he/she is an assigned user he/she will be able to see the sub-process information in the Pending list. Furthermore, he/she will be able to access all the parent’s case information.
1. In the Modules View go to the process properties right clicking on it.
2. In the properties window choose the As Parent case security.
With this configuration, the users assigned to the sub-process will also be able to have access to the parent process information.
Private security with sub-processes
The sub-processes that do not have As Parent security behave like any other process, Public or Private. If they are Private the users with privileges on the sub-process will not have privileges on the parent case. Similarly privileged users of the parent process will not have privileges on the sub-process. In the Purchase Request process used previously, once the boss approves the request, a sub-process is created, called Quotations. The person responsible for making quotations, a user called Quotations will be assigned. Since the user is an assigned he/she will be able to see sub-process information in the Pending list. Furthermore, he/she will be able to access the entire parent’s case information. As the sub-process DOESN’T have As Parent security, Quotations user may have access to his/her pending activities but will NOT have privileges on the parent case Purchase Request.
For this reason Bizagi will display a message informing the user that he/she does not have permission.
Expression to add one Privileged user
In a Purchase Request process we will like to restrict the information so that only privileged users can access the case (creator and assignees). Additionally we will like to include the Commercial Vice President, who has no assignment in such cases. Therefore the user must be added using an expression. To do this, we created a parameter table where the User Commercial Vice President is stored, so that we can easily access the user's ID and it can be administered in case of changes.
In step 4 (four) of the Process Wizard, go to Activity Actions to create an expression On enter of the activity.
The expression adds to the list of privileged users the Vice President. The Vice president id is found in the parameter table created and then it is saved in a variable. Then, this variable is registered in the function that adds to privileged users.
Expression to add multiple Privileged users
In a Purchase Request process we will like to restrict the information so that only privileged users can access the case (creator and assignees). Additionally we will like to include the Commercial Vice President and the President, who have no assignment in such cases. Therefore the users must be added using an expression. To do this, we created a parameter table where we will store both users: Commercial Vice President and President, so that we can easily access the user's IDs and they can be administered in case of changes.
In step 4 (four) of the Process Wizard, go to Activity Actions to create an expression On enter of the activity.
The following expression adds to the list of privileged users the President and the Vice President. If there were more users, the expression would add them as well. All records of the parameter table are found. The user’s ids are stored in an array. The this array is registered in the function that adds the privileged users.
The Purchase Request process of the examples given can be downloaded free from our Process Central.
Manage privileges through the SOA layer
You can allow access to case so as to include a privileged user dynamically using the SOA layer. To do this, send the user name and domain through an interface and it will automatically add the user to the privileged list. The user and domain names must be known in advance and must be sent from an external system.
Example to add privileged users through SOA layer
In the Purchase Request process the Commercial Vice President must have privileged over a case, so he can view its information. Assuming that this case is already closed and its case number is known, it is number 300, privileges are granted from an external application, invoking Web services through the Bizagi SOA layer.
The web service method to be invoked to grant access to users is grantCaseAccess available in the WorkflowEngineSOA.asmx.
The XML input for the invocation of this method for the mentioned example is given below:
Privileges can be to more than one user, and for more than one case if a web service is invoked. To see an example of this, review the following.
Restricting users through SOA layer
Fort the Purchase Request the following conditions must be followed:
- User CommercialOperator2 should not have access to the case 300.
- User CommercialOperator1 should not have access to the case 301.
- User ommercialOperator1 should not have access to the case 302.
- User CommercialVicePresident should not have access to the case 302.
Assuming that these cases are closed, restricted privileges will be configured from an external application, invoking Web services through the Bizagi SOA layer. The web service method to be invoked to restrict access to users is revokeCaseAccess available in the WorkflowEngineSOA.asmx. The XML input for the invocation of this method to include all 4 changes mentioned above is shown below:
Related Attributes
The Purchase Request Process mentioned in all examples can be downloaded for free in our Process Central.
<comments/>
