piątek, 10 lutego 2017

jBPM 7 - case management security

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:
by default three of these operations:
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:

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.

That's it folks, stay tuned and share your feedback!

3 komentarze:

  1. Maciejs, there's a good ACL framework in place for KIE Workbench, available in kie-wb-common IIRC.. it might be worth speaking with David G about integration into Case Applications?

    1. yes, I am aware of it and it could be useful when kie-wb-common is in use while this shows that the engine itself can already protect the case instances from unauthorised access. As is can be used via REST/JMS api of KIE Server UI security is not enough. Moreover, this security is based on data of the case instance rather than operations only. So given user can have access to case instance 1 to cancel it while (s)he won't have access to do so for case instance 2. Last time I checked the ACL that was not possible. It might have changed...

  2. Good information href=”https://indglobal.in/”>website design in bangalore
    href=”https://indglobal.in/”>ecommerce website design in bangalore
    href=”https://indglobal.in/”>mobile app development