IBM WebSphere V5.0 Security - CGISecurity

LTPA does not necessarily require that a reverse proxy be involved in
authentication. For example, a user can receive an LTPA cookie from a Domino
server after successful authentication, and then use that cookie when
communicating with a WebSphere Application Server which trusts the LTPA
token issued by the Domino server. In real-world applications, however,
authentication is usually performed by a reverse proxy, and the rest of this
discussion will assume that scenario, as shown in Figure 12-4.
User Registry
Client
1. Request
2. Auth. Challenge
WebSEAL
c_user
c_pwd
4. Authenticate
3. Challenge
Response
BA Header:
c_user:c_pwd
LTPA
Cookie
LTPAToken:
User: c_user
5: Request
7: Response 6: Response
LTPA
WebSphere
Application Server
user:
c_user
Figure 12-4 LTPA Information flow
1. An unauthenticated client issues a request for a secure resource which is
intercepted by the reverse proxy (WebSEAL).
2. WebSEAL issues an HTTP authentication challenge to the client. Note that
WebSEAL could be configured to provide a login form instead, but the overall
flow of information would remain the same.
3. The client responds to the authentication challenge with a new request
containing the client’s userid (c_user) and password (c_pwd) in the HTTP
Basic Authenticaion (BA) Header.
4. WebSEAL authenticates the user against the user registry using c_user and
c_pwd.
5. WebSEAL constructs an LTPA token and attaches it to an LTPA cookie which
is associated with the request sent to the WebSphere Application Server.
WebSEAL can (and should) filter the client’s username and password out of
the BA Header in the request sent to WebSphere because WebSphere will
not need this information. When WebSphere requests the LTPA cookie from
WebSEAL, it decrypts the LTPA token and verifies that the signature is
Chapter 12. Tivoli Access Manager 387