Configuring a custom authenticator plug-in
IBM® Business Automation Workflow Workflow Center supports the use of a custom authenticator plug-in to work with your third-party authentication single sign-on (SSO) environment.
Before you begin
- The desktop Process Designer is deprecated. Use the Process Designer instead.
- Verify the type of third-party authentication SSO that you are using, for example, IBM HTTP Server (IHS) or SiteMinder.
- Business Automation Workflow provides the plug-in extension point and the required interfaces. You must build the plug-in and define the underlying logic that interacts with the user and your SSO solution. This requires Eclipse plug-in development skills.
- If the custom authenticator configuration is completed before you install desktop IBM Process Designer, it can be included with desktop Process Designer.
- The httpProtocolOnly property must be set to true for desktop Process Designer, which is the default setting. See Configuring the httpProtocolOnly property for the desktop Process Designer.
- For some external links to work properly with a custom authenticator plug-in, set
add-redirect-url-credentials
to false, for example, the generated report link for a process application. For information about setting properties, see Connections from IBM Process Designer to Workflow Center.
About this task
You build a custom plug-in that defines a login authenticator in desktop Process Designer. The login authenticator must declare an extension for client-side login logic to address special authentication requirements from the server side. When authentication is triggered, Process Designer uses the custom plug-in to trigger the login logic. The authenticator extension point is an API that is provided in the Eclipse plug-in format.
The authenticator API can return two sets of security tokens:
- The first set of security tokens is shared among all connections that use Java™ HTTP clients that are triggered by user Create, Read, Update and Delete (CRUD) activities in one desktop Process Designer. This set supports inactivity timeouts on user interaction requests.
- The second set of security tokens is shared during desktop Process Designer and Workflow Center communication, CometD initialization, and the use of embedded browsers. This set does not support inactivity timeouts.
Note: If the authenticator API returns only one set of security tokens, all HTTP clients in
desktop Process Designer share that set. The same set
of security tokens is used for polling and user actions. Active polling prevents inactivity
timeouts. If you use a custom plug-in and want to support inactivity timeouts, your plug-in must
support two sets of security tokens.