Long running processes and service authentication – SAML tokens to the rescue?

By
  • Blog
  • >
  • Long running processes and service authentication – SAML tokens to the rescue?
TOPICS

30 Day Free Trial

Bring together legacy systems, RPA bots, microservices and more with Camunda

Sign Up for Camunda Content

Get the latest on Camunda features, events, top trends, and more.

TRENDING CONTENT

 

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:

example process

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:

  1. 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.
  2. 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.

Try All Features of Camunda

Related Content

We're streamlining Camunda product APIs, working towards a single REST API for many components, simplifying the learning curve and making installation easier.
Learn about our approach to migration from Camunda 7 to Camunda 8, and how we can help you achieve it as quickly and effectively as possible.
We've been working hard to reduce the job activation latency in Zeebe. Read on to take a peek under the hood at how we went about it and then verified success.