I need more context information to answer this question. In general, the job contains only the information of the current element that is executed. Workflow instance variables are a way to provide or pass additional informations.
Hi Philipp - Thanks for the response. We’re a large organisation and looking at federating out building of processes and enabling reuse. With our APIs each consumer of an API is authorised. We need a similiar level of control over sub-processes so that we can enable reuse across the organisation. What we would like to be able to do is have a way to authorise what has called the sub process. To do this we need a tamper proof way of getting the identity of what has called it. Unfortunately passing in a variable would be subject to tampering…
There is no authorization within Zeebe to prevent that a sub-process is called from another workflow.
One way is to use workflow instance variables. When the sub-process is created then it checks if the variable has a specific value (e.g. a tenant-id or organization name). If the value doesn’t match then it ends the sub-process without performing the checks.
This check could be also done within the workers of the sub-process or using data of the application context.
Hi Philipp - unfortunately it wouldn’t be secure enough. Is there a possibility of me raising a feature to get this included? The ask would be to include the id and name of the calling process in the sub-process…
For us this would be ok. For example it you have the situation:
Process A calls Process B calls Process C
We would authorise Process B to call Process C and
Process A to call Process B.
Process C doesn’t need to know that Process A is at the top of the chain as by inference it has the right to call process C having been given the rights to call Process B.