Chapter 4. Configuration and customization 163
The value is set in the default WebSEAL configuration file:
[header-names]
server-name = iv_server_name
This setting controls the name of the header used to pass the name of the server
to junctioned applications.
For example, when server-name = iv_server_name, and the WebSEAL instance
is default-webseald-seal1.itso.ibm.com, WebSEAL passes the following
header to the junction:
iv-server-name:default-webseald-seal1.itso.ibm.com
4.9.5 Using LTPA authentication with WebSEAL
WebSEAL can provide authentication and authorization services and protection
to an IBM WebSphere or Lotus Domino environment. When WebSEAL is
positioned as a protective front end to WebSphere or Lotus Domino, accessing
clients are faced with two potential login points. Therefore, WebSEAL supports a
single sign-on solution to one or more IBM WebSphere or Lotus Domino servers
across WebSEAL junctions.
WebSphere provides the cookie-based lightweight third-party authentication
(LTPA) mechanism. You can configure WebSEAL junctions to support LTPA and
provide a single sign-on solution for clients.
When a user makes a request for a WebSphere or Lotus Domino resource, the
user must first authenticate to WebSEAL. Upon successful authentication,
WebSEAL generates an LTPA cookie on behalf of the user. The LTPA cookie,
which serves as an authentication token for WebSphere or Lotus Domino,
contains user identity and password information. This information is encrypted
using a password-protected secret key shared between WebSEAL and the
WebSphere or Lotus Domino server.
WebSEAL inserts the cookie into the HTTP header of the request that is sent
across the junction to WebSphere or Lotus Domino. The back-end WebSphere
or Lotus Domino server receives the request, decrypts the cookie, and
authenticates the user based on the identity information supplied in the cookie.
To improve performance, WebSEAL can store the LTPA cookie in a cache and
use the cached LTPA cookie for subsequent requests during the same user
session. You can configure lifetime timeout and idle (inactivity) timeout values for
the cached cookie using parameters in the WebSEAL configuration file.
The creation, encryption, and decryption of LTPA cookies basically introduces
processing overhead. The LTPA cache functionality enables you to improve the
164 Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0
performance of LTPA junctions in a high load environment. By default, the LTPA
cache is enabled. Without the enhancement of the cache, a new LTPA cookie is
created and encrypted for each subsequent user request.
Having the LTPA cookie enabled is independent of the basic authentication
header. This means that with the LTPA cookie inserted into the request header, it
is still possible to have the BA header to carry any authentication information to
the back-end server, depending on the –b option specified during the junction
creation. The usage of the BA header depends on the configuration of the
back-end WebSphere or Lotus Domino server.
Configuring an LTPA junction
Enabling single sign-on to WebSphere using an LTPA cookie requires the
following configuration tasks:
1. Enable the LTPA mechanism in the WebSphere Administrative console.
2. Generate the LTPA key file used for encryption of the identity information.
3. Create an LTPA-aware junction with location of the LTPA key file and the
password to this key file.
The following options are necessary to the standard junction and virtual host
junction create commands:
-A Enables LTPA cookies. LTPA version 1 cookies (LtpaToken) and LTPA
version 2 cookies (LtpaToken2) are both supported. LTPA version 1
cookies are specified by default. LTPA version 2 cookies must be specified
with the additional -2 option.
-2 Specifies that LTPA version 2 cookies (LtpaToken2) are used.
-F The “keyfile” option and argument specifies the full path name location (on
the WebSEAL server) of the key file used to encrypt the identity
information contained in the cookie. The shared key is originally created on
the WebSphere server and copied securely to the WebSEAL server.
-Z The “keyfile-password” option specifies the password required to open the
key file. The password appears as encrypted text in the junction XML file.
Use these options in addition to other required junction options when you create
the junction between WebSEAL and the back-end WebSphere server. For
example (entered as one line):
pdadmin> server task default-webseald-webseal.ibm.com create ... -A -F
"/abc/xyz/key.file" -Z "abcdefg" ...

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.