jBPM 7 - case management security

jBPM 7 – case management security

by Maciej Swiderski - February 10, 2017
Process Article

Case management puts additional requirements on business automation. In many cases it’s much more domain specific than business process management and thus will then have different (or better would be to say – extended) needs. This is no different when it comes to security.

Cases come with so called case roles. These are generic participants that will be involved in case handling. These roles can be assigned to user tasks or used as contact references. Though they are not defined in cases as concrete users or groups of users. Case roles are on case definition level to make the case definition independent of the actual actors involved in given case instance.

Case instances in turn, are those that are focused on individuals that will actually do the work as part of case handling. To provide this required flexibility case management in jBPM comes with case role assignments that allow to provide actual actors or groups for given role. Case role assignment can be given at the time case instance is started or can be set on already active case instance.

Note: Case role assignment can be modified at any time as long as case instance is active though it will not have effect on tasks already created based on previous role assignment.

General recommendation is to always start with case role assignments when starting a case instance as this will prevent situations of assigning tasks to not the correct owners.

How does it work?

By default case instance security is enabled. It does protect each case instance from being seen by users who do not belong to a case in anyway. In other words, if you are not part of case role assignment (either assigned as user or a group member) then you won’t be able to get access to the case instance. This applies to:

access to individual case instance
access to case instance details like

case file
case stages
case milestones

queries for case instances

There is one situation when the case instance security will not take any effect – it is where there are no case roles defined at all. That essentially disables the security as there is no information to base authorisation on.

Authorisation can also be turned off by system property: org.jbpm.cases.auth.enabled when set to false.

Above access is just one part of the security for case instances. In addition, there is case instance operations that can be restricted to case roles. Here is the list of currently supported case instance operations that can be configured:

CANCEL_CASE
DESTROY_CASE
REOPEN_CASE
ADD_TASK_TO_CASE
ADD_PROCESS_TO_CASE
ADD_DATA
REMOVE_DATA
MODIFY_ROLE_ASSIGNMENT
MODIFY_COMMENT

by default three of these operations:

CANCEL_CASE
DESTROY_CASE
REOPEN_CASE

are protected with following roles:

owner
admin

again, these are case roles so based on case role assignments can differ between case instances. Thus allowing maximum flexibility in how to utilise them.

security for case operations is configurable via simple property file called case-authorization.properties that should be available at root of the class path upon start of the case application. Format of this file is extremely simple:

OPERATION=role1,role2,roleN

Some might say that it’s too generic to have single config file for all possible case definitions but that’s a way of promoting thinking about case management as domain specific and to build tailored application where single configuration for case role security is certainly enough. Moreover (as everything in jBPM) AuthorizationManager for case security is pluggable so if you need any specific handling you can just put your own piece of code to do so.

And at the end, let’s see this working in Order IT hardware application, in particular how can we easily restrict access to only involved people or certain actions.

KIE Community