Scenario 2: Basic authentication, identity assertion, and client certificates

This scenario is the same as Scenario 1, except for the interaction from client C2 to server S2. Therefore, the configuration of Scenario 1 still is valid, but you have to modify server S2 slightly and add a configuration for client C2. The configuration is not modified for C1 or S1.


Configuring client C2

Client C2 requires transport

layer authentication (SSL client certificates). To configure transport layer authentication:

  1. Point the client to the sas.client.props file using the property.

    All further configuration involves setting properties within this file.

  2. Enable SSL.

    In this case, SSL is supported but not required:,

  3. Disable client authentication at the message layer.,

  4. Enable client authentication at the transport layer where it is supported, but not required:,


Configuring server, S2

In the administrative console,

server S2 is configured for incoming requests to SSL client authentication and identity assertion. Configuration for outgoing requests is not relevant for this scenario.

  1. Enable identity assertion.

  2. Disable user ID and password authentication.

  3. Enable SSL.

  4. Enable SSL client authentication.

You can mix and match these configuration options. However, a precedence exists as to which authentication features become the identity in the received credential:

  1. Identity assertion

  2. Message-layer client authentication (basic authentication or token)

  3. Transport-layer client authentication (SSL certificates)


See Also

Scenario 1: Basic authentication and identity assertion
Scenario 3: Client certificate authentication and RunAs system
Scenario 4: TCP/IP transport using a virtual private network
Scenario 5: Interoperability with WAS Version 4.x




WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.