Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0

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" ...