Camunda support for SSO SAML-based integration

[davy...@gmail.com]

Hi,

We have the scenario where a business process is exposed as a SAML-secured webservice. When the webservice encapsulating the business process is called, we get a SAML token identifying who called the webservice. The business process itself calls in its flow an EJB service and another SAML-secured webservice. We want to propagate the identity information of the incoming SAML token to the EJB and the other webservice.

Are there already some security API's in Camunda that can help us achieve this?

Best regards,
Davy Toch

[Roman Smirnov]

Hi Davy,

sorry, for the late answer!

The engine preserve in the ThreadLocal the current user as a String (but in case of a asynchronous continuation not anymore). Do you want to do something like JaaS?

Cheers,

Roman

[davy...@gmail.com]

Hi Roman,

Thanks for the information.

For example a complete suite like Oracle BPM supports the JaaS Subject identity propagation between the process steps, even if the step is called asynchonously (the Subject is actually stored as part of the process instance information in the Oracle BPM database). Also it seems to support SAML token propagation in case the BPM process calls are wrapped in a SAML-secured webservice and also conversion of the SAML token to a JaaS subject (and vica versa?).

I think that at least a part of the SAML token problem is out-of-scope of what Camunda has to offer and is more in the realm of what the JaaS identity providers of a J2EE container need to offer. For example in Oracle WLS the SAML identity provider can map a SAML token to a JaaS Subject, so I think the Oracle BPM simply calls the identity provider to convert the SAML token to the JaaS Subject.

However automatically storing the JaaS subject in the process instance in order to be usable in all BPM steps is perhaps something that may be considered as a feature to be offered in the BPM engine. But there is always a workaround if it is not available : we can store it ourself in a process instance variable if needed. One thing I didn't yet consider regarding the JaaS Subject : we might have a scenario where multiple JaaS Subjects have to be managed : JaaS Subject for identifying who initiated the process instance, JaaS subject for identifying who proceeded the process state in a given step, ... . Perhaps this is a reason to leave this complexity to the client using the BPM engine and not to add this as a standard feature in the BPM engine?

Best regards,
Davy Toch

[Roman Smirnov]

Hi Davy,

you put it in a nutshell: we do not want to have this complexity inside the engine.

Cheers,

Roman