Chapter 4. Configuration and customization 149
argument that specifies the key-label of the required certificate as stored
in the WebSEAL key database.
b. Back-end server validates WebSEAL identity information in a Basic
Authentication (BA) header (–B, –U, –W).
Use the –B –U username –W password option to enable WebSEAL
authentication using basic authentication. In this type of configuration the
–b option does not work, as internally the –B option uses –b filter.
4.8.2 WebSEAL-to-WebSEAL junctions over SSL
Tivoli Access Manager supports SSL junctions between a front-end WebSEAL
server and a back-end WebSEAL server. Use the –C option with the create
command to junction the two WebSEAL servers over SSL and provide mutual
authentication. Additionally, the –C option enables single sign-on functionality
provided by the –c option.
The –c option allows you to place Tivoli Access Manager-specific client identity
and group membership information into the HTTP header of the request destined
for the back-end WebSEAL server.
Both WebSEAL servers must share a common user registry. This configuration
allows the back-end WebSEAL server to authenticate the front-end WebSEAL
server identity information.
If the WebSEAL-to-WebSEAL junction and the back-end application server
junction both use the –j junction option (for junction cookies), a naming conflict
can occur between the two junction cookies created by each of the two
WebSEAL servers. In this case, an intermediary WebSEAL server changes the
following parameter to
yes in the WebSEAL configuration file:
hostname-junction-cookie = yes
4.8.3 Stateful junction
Back-end servers that run Web-enabled applications can be replicated in order
to improve performance through load sharing. By default, Tivoli Access Manager
balances back-end server load by distributing requests across all available
replicated servers. Tivoli Access Manager uses a
least-busy algorithm. This
algorithm directs each new request to the server with the fewest connections
already in progress.
However, when WebSEAL processes a request over a stateful junction,
WebSEAL must ensure that all subsequent requests from that client during that
150 Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0
session are forwarded to the same server, and not distributed among the other
replicated back-end servers according to the load balancing rules.
Configuring stateful junction
To configure a stateful junction you need to use –s junction options. The –s
option is appropriate for a single front-end WebSEAL server with multiple
back-end servers junctioned at the same junction point. When a new junction is
created to a back-end Web application server, WebSEAL normally generates a
Unique Universal Identifier (UUID) to identify that back-end server. This UUID is
used internally and also to maintain stateful junctions. If the scenario involves
multiple front-end WebSEAL servers, all junctioned to the same back-end
servers, you must use the –u option to correctly specify each back-end server
UUID to each front-end WebSEAL server.
Figure 4-8 Stateful junction and load balancing mechanism
Multiple front-end servers require a load balancing mechanism to distribute the
load between the two servers. For example, an initial state could be established
to a back-end server through WebSEAL server 1 using a specific UUID.
However, if a future request from the same client is routed through WebSEAL
server 2 by the load balancing mechanism, the state will no longer exist, unless
WebSEAL server 2 uses the same UUID to identify the same back-end server.
Apply the following process for specifying a UUID during the creation of a
1. Create a junction from WebSEAL server 1 to each back-end server. Use
create –s and add.
2. List the UUID generated for each back-end server during step 1.

Get Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0 now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.