When executing long running business processes which include service invocations you often have to solve a problem: What credentials should you use when calling the service?
Let’s have a look at a simple example:
A user might start the process manually. Then service 1 might be executed with the credentials of this user. But how about service 2? Should it be executed with credentials from the first user or the user who finished the user task? How about service 3?
From our experience, there is no rule of thumb but it needs to be decided based on the project requirements. All of the three options are valid:
- The starting user credentials will be used for all service calls in the process
- The last user credentials will be used for the next service calls (can get tricky with parallel paths by the way)
- Technical Users will be used for the service calls. This technical user might be defined for every service task.
If you go for one of the first two options, a very interesting question arises:
How can we use user credentials later in a process – which is potentially long running?
In our example, at least the timer takes 2 weeks! And all wait states (see Wait States for a list of BPMN wait states) may take a long time. As storing passwords is not a safe option the answer is: use authentication tokens. In most environments, this means to use SAML tokens. This token is issued by some token server (where you normally logged in once with your password) and can then be used for authentication. It has a validity but can typically be renewed (as two weeks is a long time to wait).
Some environments have proprietary alternatives, e.g. IBM uses LTPA tokens. Even if the principle keeps the same, the implementation gets quite tricky, as you have to use proprietary and undocumented API. Especially with LTPA tokens there was a big puzzle to solve: How to renew the token? We could see that IBM can do this internally, but leveraging it was a bit tricky. In a recent project, our great partner Novatec faced this issue and was able to solve it. Great job guys!
To use security tokens in Camunda BPM you simply have to hook in the necessary functionality – which consists only of a couple of lines of code:
- An ExecutionListener being executed when a new process instance is started. It gets the security token and stores it as process variable (as byte array). You might want to save the user name too. As they operated in a WebSphere environment, login is handled by JAAS and the application server provided the security token out-of-the-box. So this was straight forward.
- An extension to the process application class, which intercepts calls to the process engine core. This is a perfect place to set the security context if not yet done. You can load the Security Token from the process variable and set it at the application server. Details depend a bit on the environment / application server.
This can be packaged as “Process Engine Plugin” and added to Camunda BPM in a generic way. The concept is applicable to all environments, even using proprietary security tokens, but may differ in details of the source code.
If you are interested in any details, contact us – as we cannot publish the code due to NDA agreements. We are happy to assist – so are our competent partners – as for example Novatec.
