IBM BS029ML Self Help Guide - Page 54
Trust Association with WebSEAL, Single sign-off
View all IBM BS029ML manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 54 highlights
Single sign-off One often neglected aspect of SSO is the allied sign-off or sign out action associated with a user session. This is especially important because it is not uncommon for the back-end servers participating in the SSO realm to create and issue their own authentication cookies as part of the transparent SSO process. Unfortunately, if a user explicitly logs out of WebSEAL, but does not close or terminate the browser session, the back-end server cookies will remain active within the browser session. This, then creates a security threat by raising the risk that an unauthorized user may gain access to restrictive information, although it should be acknowledged that this kind of threat is only applicable to shared desktops and workstations, such as kiosks. To overcome this threat, the recommendation is to embed JavaScript code capable of searching and destroying all applicable cookies in the page that WebSEAL redirects to after logging out a user. 2.6.4 Trust Association with WebSEAL In this configuration, the underlying WebSphere Application Server instance of WebSphere Portal Server needs to be configured to explicitly "trust" the WebSEAL server so that if WebSEAL has already authenticated a user, WebSphere Application Server will not challenge the user to authenticate again. WebSphere Application Server provides a Trust Association Interceptor (TAI) framework for this purpose. Based on the established trust, WebSphere Application Server can map the delegated credential from WebSEAL to a valid WebSphere Application Server credential. The identification of the user must be passed to the TAI in a header called iv-user, which is inserted by WebSEAL into the HTTP Header of the request sent from WebSEAL to the WebSphere Application Server. Note that while WebSEAL can be configured to pass the user identity in other ways, the iv-user header is the only one supported by the TAI. Also note that the user password is not passed in the HTTP Header (for security reasons). After the TAI processing is successful, WebSphere Application Server creates a user authentication cookie called an LTPA token (we recommend using the LTPA token2). This is identical to the process that occurs when the out-of-the-box SSO with WebSphere Portal Server is enabled. With the availability of the new TAI++, TAI now does not query the User Registry (LDAP) directly for Trust Association Interceptor processing. Instead, the new Interceptor class TAMTrustAssociationInterceptorplus contacts the Tivoli Access Manager (TAM) Authorization Server, which then proceeds to check the User Registry (LDAP). The benefit that this brings to a solution is that the TAM Authorization Server does not have to be the actual TAM Policy Server. As such, a local TAM Authorization Server replica can be installed, either alongside each WebSphere Portal Server node, or on an additional number of dedicated servers. As one might expect, this requires an additional amount of effort and planning, not to mention system resources. However, this is very beneficial when overall performance is a concern, as requests can be offloaded and cached at the TAM Authorization Server replicas, which may or may not be local to each WebSphere Portal Server node, greatly improving performance. After successful processing, TAI++ adds the PDPrincipal to the WebSphere subject or context, which can be retrieved by downstream applications. Furthermore, with the new TAI++, one can add custom attributes to the subject or context in the form of Java sets. After the TAI++ has accepted the user identification and WebSphere Application Server has created the LTPA token, the WebSphere Member Manager component of WebSphere Portal Server performs additional queries against the User Registry (LDAP). In particular, WebSphere Member Manager does an LDAP search to get group and additional attribute information from the LDAP. WebSphere Portal Server also queries the resource mappings from the Portal database, before displaying the applicable Portal pages. 40 IBM WebSphere Portal V6 Self Help Guide