cancel
Showing results for 
Search instead for 
Did you mean: 

process definition security

heymjo
Champ on-the-rise
Champ on-the-rise
Hi,

Does BPMN2 foresee a way to secure the start event in a process ? Like you have assignment groups for a task, is there something similar for the start event ? In our case not every user is allowed to start (or even see) all available workflows, they are divided by business department with each their own responsibilities.

What i am trying to get to with above question is this: if we have one activiti database per organization, and all process definitions are put there, how can we prevent users from starting workflows they have no business starting ? One way would be to dedicate one activiti database to an application, this is doable but has its own set of advantages/disadvantages in terms of management.

How do other people deploy activiti for multiple applications / departments ?

Jorg
2 REPLIES 2

frederikherema1
Star Contributor
Star Contributor
In activiti, there is no way of 'limiting' the process that can be started by a specific user, based on roles/groups. The way the alfresco-integration fixes this (for multi-tennant setups) is prefix the workflow-definitions with the tennant domain. The layer on top of activiti (which alfresco actually uses and exposes) filters the ones out, which are in another domain (based on their name).

heymjo
Champ on-the-rise
Champ on-the-rise
yes i had thought about something like that as well, maybe even using the category attribute of a process definition instead of prefixing it.

The issue essentially is that you need to give your users(=applications) a database connection to the schema, so even using a filtering layer and telling them to use only that layer for obtaining process definitions / instances only covers partially the security issues (they can always bypass the filtering layer and use activiti engine directly). Since we have Oracle we can use virtual private databases (VPD) but i did not find a good column in the activiti tables to apply the policy to. For our inhouse products that need to be 'multi-tennant' we always foresee an 'application' column in all tables, so when the user logs on to an application the VPD strips out all data not linked to the current app for all tables - this cannot be circumvented by the schema user.

Maybe the best option is to have an activiti database per application, this makes it easier to evolve versions as well but has the management overhead ofcourse. a tradeoff as always …