IBM Business Process Manager (BPM) started to allow the integration with Enterprise Content Management (ECM) systems in V8.0. As communication standard, the Content Management Interoperability Services (CMIS) are used. They define different protocol bindings: Web Service, AtomPub and – since CMIS 1.1 – Browser binding. IBM BPM uses the Web Service binding. It provides a standardized definition of operations end entities through the Web Service Definition Language (WSDL) and XML Schema Definition (XSD).
For Web Services, the security aspects are specified by the OASIS Web Services Security (WSS) TC. They define standardized ways to propagate user contexts during a web service invocation.
When you integrate IBM BPM with an ECM system, you start by defining an Enterprise Content Management service in the application settings of your toolkit or process application. One of the settings is the Always use this connection information checkbox that determines which credentials are passed to the ECM system. If you enable this checkbox, IBM BPM will send a WSS UsernameToken in the outbound web service message containing the username and password of the user you specified. It will also send a basic authentication HTTP header with the same user credentials. Enabling this checkbox has some disadvantages if you let end users make use of the content functionality, because the subject of the logged in user will not be propagated to the ECM system. You therefore lose all kinds of auditing and fine-grained authorization support that your ECM system has because the ECM system only sees the technical user you defined instead of the real end user.
So, the better choice is to not enable this checkbox. Then, IBM BPM will propagate the credentials of the currently logged-in IBM BPM end user to the ECM system. A logged in end user only exists when a user runs a user task or standalone human service. If you use Content Integration steps in integration services that are used as implementation of a system task, then IBM BPM will still use the user you defined in the ECM server definition to authenticate at the CMIS endpoint. IBM BPM will also use the specified user for some system-required calls, for example to retrieve repository- and type-information from the ECM system. You therefore cannot leave username and password empty.
To successfully propagate a user context, some configuration work to establish single sign-on is required. We will look at approaches to reach this today and in the next weeks.
Target ECM system is hosted on WebSphere Application Server and the same user registry is used
The simplest scenario is if your ECM system has its CMIS endpoint hosted on WebSphere Application Server (WAS), for example IBM Content Navigator that contains the CMIS implementations for IBM Content Manager and FileNet Content Manager and if the user registry is configured the same in both your IBM BPM as well as your ECM system, for example by using the same LDAP server under Federated Repositories. Then you can use Lightweight Third-Party Authentication (LTPA) to propagate the user identity. LTPA is an IBM proprietary authentication technology supported both by WebSphere and Domino products.
To establish LTPA based single sign-on between two WAS cells, a common LTPA key must be used. This can be reached by exporting the key from one cell and importing it into another cell as described in Import and export keys.
Beside that you need to make sure that the Web Service client sends LTPA tokens and that the Web Service provider accepts them.
Web Service client configuration
The client side is easy as nothing needs to be done. IBM BPM uses a managed web service client with a policy set and binding that are by default configured to send an LTPA token. You can find them in the WAS admin console in Services > Service Clients. The relevant service clients for the single sign-on access to ECM system are prefixed with SSO.
There are in total six clients for different CMIS defined web service ports.
You can click on each of them to see the attached policy set and binding. The policy set defines which service features are required. The binding then specifies how these features are configured. By default, the IBM BPM CMIS service clients use the BPM SSO Policy Set and the BPM SSO Client.
The policy set specifies that an LTPA token is to be sent. To see this, go into its details, to WS-Security > Main policy > Request token policies.
The binding specifies to do so as it has an outbound authentication token. To see this, go into its details, to WS-Security > Authentication and protection.
Web Service provider configuration
The Web Service provider needs to be configured to accept the LTPA token. For the CMIS implementation for IBM Content Manager and FileNet Content Manager, this requires the CMIS application to be configured and deployed correctly. This is typically done using the IBM Content Navigator Configuration and Deployment Tool. This graphical user interface allows to deploy new and update existing deployments for the IBM Content Navigator application but also for the CMIS endpoint for IBM Content Manager and FileNet Content Manager.
As a step of a so-called deployment profile, there is the Configure the IBM CMIS client authentication method step. There you need to specify WS-Security Authentication instead of the default HTTP Basic Authentication. The default cmis_auth_policyset is fine for our use case as it specifies to consume LTPA tokens.
Note: WS-Security Authentication is only available for the CMIS 1.0 implementation. It is not supported for the CMIS 1.1 implementation. This is not a problem because IBM BPM does not require any CMIS 1.1 capabilities.
And that’s it. With this setup, you are ready to configure your ECM server to not always use the technical user. If you then let your end users create or update documents and folders in human services – for example in the Document Explorer or Document List coach view – then you will see that these objects are created with the correct creator.
Conclusion and outlook
We looked at the options to connect an ECM server using a technical user or to propagate the end user credential with single sign-on. We were looking at the simplest option to establish single sign-on through LTPA and looked at the Web Service client and provider specific requirements.
Next week we will set up the single sign-on based on Security Assertion Markup Language (SAML) tokens to gain more flexibility and interoperability with non-IBM products.
Other articles in this series:
- Single sign-on with an external Enterprise Content Management system - Part 2: SAML based
- Single sign-on with an external Enterprise Content Management system - Part 3: SAML based with customized SAML token content
- Single sign-on with an external Enterprise Content Management system - Part 4: HTTP header based