We are using Camunda as an embedded process for executing workflows which call back-end services containing ACL checks via Java delegates. This requires an authentication token to be present in the SecurityContextHolder for the current thread. This works for synchronously executed workflows but fails for async, call activity and timer based workflows since the authentication token will not be present.
We have considered creating a service user that has permissions/roles to access all objects but this introduces some security concerns.
We have considered storing the authentication token as a variable but this fails for timer based jobs since variables do not persist between executions.
Has anyone tackled this scenario?
Looks like you want to authenticate/authorize access to back-end services based on user’s attributes or role.
Assuming that you want to pass through the user’s token into back-end services:
- User logs into Camunda
- Camunda launches a process on behalf of user
- Within this process, a task launches delegate. This delegate then calls into back-office services.
- The Deligate passes in user’s token (etc), to back-office service.
I’ve done this via generated user-token. Token is time sensitive so we have some way to control access. Never pass in clear text (etc)
- user logs into Camunda - but, getting to this point means user is already identified and granted access to Camunda services
- when user launches camunda process, we associate user’s participation. Dynamic role-based access (RBAC) is good to have at this point but not essential (attribute vs role comes into play with additional process types). Reason for RBAC is that we’re essentially defining access requirements via process context (participant to lane or pool association/binding).
- User’s token is referenced, or passed into a task.
- as task executes, delegate calls auth/auth services and verifies user’s token (i.e. “is it still good” - etc…). Based on policy, token may require a refresh.
- At this point, we may hand-off to a service-based identity for execution. But, saving associated upstream history (preserving ownership/transaction).
- Back-end service, upon receiving Camunda task request (along with tokens), verifies all above (per policy) and both tracks and grants access. Risk management kicks in and begins tracking/watching.
All of this (above) requires CPU/IO effort. And, some optimization required, or allowed, per policy.
This blog post may be of interest…
Thank you for you response. Your summary is spot on and your outline will be helpful.
The blog post does address our situation. Thank you for sharing.
KeyCloak is a good place to test out concepts - it’s open-source, and plugs right into Wildfly. KeyCloak includes test utilities for Auth2/OpenID tokens.