BPMN Security Extension: Modeling security rules into BPMN

Hi all

I have been working on a BPMN security rule system as I have found we write many of the same types of restrictions in scripts, delegates and listeners throughout a BPMN, and I wanted to bring this to a modeling capability.

I noticed we write many of the same rules in a Unit Test, so some of the logic is pulled from the same style of writing assertions.

The goal here is to write “security rules” that can be used as permission layers. These are similar to assertions that we typically write in unit tests, scripts, and delegates.

My prototype has these implemented using the Camunda Extensions attributes and using a BPMN Parse Listener that adds the specific rules to their relevant activities.

Examples of rules:


// current task cannot be claimed by the same user that claimed/completed Task_13d9vmo
@Security:claim
getAssignee() != task('Task_13d9vmo').getAssignee()

// Task can only be completed on a weekday and between the hours of 9am and 5:30pm
@Security:completion
getCurrentDate().getDayOfWeek().is().weekday() && getCurrentDate().is().between('09:00','17:30')

// Once a task is claimed, it must be completed by that user
@Security:unclaim
cannotUnClaim() //equivalent to returning false

// If a assignee/claimer is part of a specific group then they cannot claim / do this task
@Security:claim
getAssignee().getGroups().contains('group11')

// If a user is part of someBadGroup then they cannot start this process
@Security:startableby
!getCurrentUser().getGroups().contains('someBadGroup')

// This process cannot be started if an existing process for the same definition id is currently active
@Security:startableby
processInstanceQuery().processDefinitionId(execution.getProcessDefinitionId()).active().startedBy(getCurrentUser()).count() == 0

Where the extension property name is @Security:startableby and the value would be a EL / SPEL expression such as: processInstanceQuery().processDefinitionId(execution.getProcessDefinitionId()).active().startedBy(getCurrentUser()).count() == 0

Any thoughts?

Anyone have further types of rules?

My current list was:

  1. Claim
  2. unclaim
  3. complete
  4. Cannot be completed by the user who did X task
  5. Cannot be member of group
  6. cannot be member of same group as user who complete X task
  7. must be specific date/time
  8. must be within a range
  9. cannot have other active processes of X Ids
  10. Variable value must exist or have specific value
  11. Some service must be online

Additionally I was looking at using BPMN “groups” element to create more complex rule assignment so you can create a group element that had 3 tasks inside of it, and apply a rule on the group such as:

@Security:tpi
getAssignee() != task(groupRule().firstTask().getAssignee()), which would place this rule on each each task in the group, except for first task.

And sure you can imagine the various layers that can be built around this.

Note that it is designed to be able to place multiple rules on a single activity: so that you can stack security rules.

Note the current design is setup to always expect the expression to resolve to True.

Just following up on this. Anyone have any thoughts? Moving forward with further impl of this.
@jangalinski @Niall ever have similar scenarios?

@Webcyberrob did you come across any similar scenarios?

Hi Stephen,

Its an interesting concept…

In my experience, there are two very common access control requirements;

  1. The user has access authorised - for these Id typically use group membership in the IAM domain and the authorisation service within the engine.
  2. The maker/checker or four eyes pattern - usually implemented with a task listener

I was reflecting on your example of a task can only be completed during office hours. If this was expanded to all tasks must be done during office hours, I would consider implementing this via the IAM system and thus prevent access to the application outside of office hours rather than implement this at a task level.

In addition - Id challenge this type of rule in a system. Lets work with a principle that we want to remove impediments to work being performed, so work should be able to be done any time. Perhaps the real requirement is the side effect of the work being done should only be during business hours. For example if completion of a task results in an SMS, we may want the SMS to only be send during business hours. In this case, the requirement is not a security access control, the process should be modelled to only send during business hours…

regards

Rob

For something like office hours, think of it like a specific task must be completed during office hours. So access to the system would not be relevant as there may be other tasks that do not have the requirement.

Security rules exist when there are strong security requirements for compliance, insider threats, etc: a task must be done on a specific location and during specific hours. If they try doing a specific hour it may just set off a flag or disallow the entire interaction