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
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" ...
Trust Association Interceptor Plus (TAI++)
Along with LTPA mechanism, WebSphere provides an additional SSO
mechanism called Trust Association Interceptor (TAI). Since WebSphere 5.1.1.
this interceptor has been named TAI++. TAI++ implies that the WebSphere security application recognizes and processes HTTP requests received from WebSEAL. WebSphere and WebSEAL engage in a contract in which the former gives its full trust to the latter, which means that WebSEAL applies its
authentication policies on every Web request that is dispatched to WebSphere.
When using Trust Association Interceptor Plus, WebSEAL authenticates the user, acquires credentials for the user from the user registry, and possibly authorizes the request at the URL level. With a successful authorization, WebSEAL augments the request with an additional HTTP header (iv-creds) that contains the user’s credentials. It also changes the password contained in the Basic Authentication header so it matches a configured SSO user.
This request is sent to WebSphere Application Server, which calls a TAI method to determine whether the request is from a perimeter authentication service that has already authenticated the user, to establish trust with the perimeter
authentication server and retrieve the credentials. This method establishes trust with WebSEAL by checking whether the Basic Authentication header contains the correct password for the configured SSO user. This is done by calling Access Manager Authorization Server to make this decision.
The iv-creds header is then extracted from the request and used to construct a PDPrincipal object. A credential object containing user and group information is constructed from information contained in the PDPrincipal. The Principal and the Credential objects are inserted into a JAAS Subject, which is returned from the call. At this point WebSphere Application Server has valid credentials that it can use for making authorization decisions in the usual J2EE manner. In addition, the Subject now contains the PDPrincipal object, which application code can access if needed.
Important points to note are:
WebSEAL needs to insert the iv-creds header into the request, not the iv-user header.
TAI++ does not directly contact LDAP, unlike the previous TAI version. It instead contacts the Access Manager Authorization Server, which validates the SSO password to establish trust with WebSEAL. This means that
additional configuration is required on the WebSphere Application Server side to ensure that the TAI can reach the Access Manager Authorization Server.
The Credential object inserted into the Subject by the TAI means WebSphere Application Server does not have to perform any additional user registry searches as part of the authentication process.
The use of TAI++ needs to be configured/enabled in WebSphere. The easiest way to perform this is by using the WebSphere Administrative console and selecting Global Security→ LTPA → Trust Association → Interceptors.
For additional information on how to configure TAI++, see:
http://www.ibm.com/developerworks/websphere/techjournal/0406_botzum/0406_bo tzum.html