Credential Mapping

By default, when a process instance is started it takes on the identity of the user who started the process. Whenever an activity in the process instance is executed, the BPM runtime authenticates the starting user’s credentials against the appropriate LDAP directory. The activity can only be executed if that authentication request succeeds.

This authentication model may not be appropriate for some business processes. For example:

• If a process takes a significant length of time to complete (perhaps months or even years) the user who started the process may have left the company before the process instance has finished. When the next activity in the process instance executes, authentication will fail as the user’s credentials have been removed from the company’s LDAP directories. The process instance will therefore be unable to progress.
• If a process contains an activity that calls a secured web service, some users may have the necessary authorization rights to start an instance of the process, but not to access the secured web service. The process instance will therefore be unable to progress beyond the call to the secured web service.

You can avoid these problems by:

• designing your application to include a "wrapper" process that calls the main business process, using a UsernameToken policy.
  Note: The wrapper process must call the main business process by invoking a concrete WSDL operation, using SOAP over HTTP as the binding type. Credential mapping cannot be performed using service virtualization as the binding type.
• configuring the BPM runtime to enforce this policy, mapping the credentials of any user starting the wrapper process to fixed credentials that will be used to run the business process.

Claim is the actual business process. CredentialMapper is a "wrapper" process that starts the Claim process.

For example, at runtime:

1. User "Joe Smith" starts an instance of the CredentialMapper process.
2. The Call ClaimBusinessProcess service task calls the Claim process. The service task uses a system participant that is configured to apply a username token policy to the outgoing service request.
3. A governance agent in the BPM runtime enforces the policy - changing the credentials passed in the service request from "Joe Smith" to "sysUser".
   Note: The Call ClaimBusinessProcess service task must use a concrete WSDL to call the Claim process, using SOAP over HTTP as the binding type.
4. An instance of the Claim process is started, running as "sysUser". As a result:
   • The Call Authorization Service service task will always be invoked using "sysUser" credentials. There is no need to ensure that "Joe Smith" (or any other user who can start the Claim process) has the necessary authorization to access the remote service.
   • When the ApproveClaim activity is executed, the "sysUser" credentials will be checked against the LDAP directory to authenticate the request. The activity can therefore proceed even if "Joe Smith" has left the company when this happens.