IBM WebSphere V5.0 Security - CGISecurity

LTPA does not necessarily require that a reverse proxy be involved inauthentication. For example, a user can receive an LTPA cookie from a Dominoserver after successful authentication, and then use that cookie whencommunicating with a WebSphere Application Server which trusts the LTPAtoken issued by the Domino server. In real-world applications, however,authentication is usually performed by a reverse proxy, and the rest of thisdiscussion will assume that scenario, as shown in Figure 12-4.User RegistryClient1. Request2. Auth. ChallengeWebSEALc_userc_pwd4. Authenticate3. ChallengeResponseBA Header:c_user:c_pwdLTPACookieLTPAToken:User: c_user5: Request7: Response 6: ResponseLTPAWebSphereApplication Serveruser:c_userFigure 12-4 LTPA Information flow1. An unauthenticated client issues a request for a secure resource which isintercepted by the reverse proxy (WebSEAL).2. WebSEAL issues an HTTP authentication challenge to the client. Note thatWebSEAL could be configured to provide a login form instead, but the overallflow of information would remain the same.3. The client responds to the authentication challenge with a new requestcontaining the client’s userid (c_user) and password (c_pwd) in the HTTPBasic Authenticaion (BA) Header.4. WebSEAL authenticates the user against the user registry using c_user andc_pwd.5. WebSEAL constructs an LTPA token and attaches it to an LTPA cookie whichis associated with the request sent to the WebSphere Application Server.WebSEAL can (and should) filter the client’s username and password out ofthe BA Header in the request sent to WebSphere because WebSphere willnot need this information. When WebSphere requests the LTPA cookie fromWebSEAL, it decrypts the LTPA token and verifies that the signature isChapter 12. Tivoli Access Manager 387