Ltpa Token Generation With Webseal; Other Tivoli Access Manager Considerations - IBM BS029ML - WebSphere Portal Server Self Help Manual

All communication should be over SSL; the link from WebSEAL to the Web server must use
client certificate authentication, and the same must be true for the link from the Web server to
the embedded Web Container of the underlying WebSphere Application Server instance of
WebSphere Portal Server. Should either link be insecure, the TAI will continue to work, but the
link will not be secure.

2.6.5 LTPA token generation with WebSEAL

With this option, one does not need to configure the Trust Association Interceptor (TAI)
framework in WebSphere Application Server at all. Instead, one configures an LTPA junction
in WebSEAL, and Tivoli Access Manager issues the LTPA token. The junction from WebSEAL
to the WebSphere Application Server is configured to pass the iv-user and iv-groups
information, and the LTPA token that is created by TAM. At the WebSphere Application
Server, TAI is not enabled and the Application Server simply receives the LTPA token in the
HTTP header request. The underlying WebSphere Application Server only creates the
session cookie for the user and assumes that this user has already been authenticated.
It should be noted that just like the approach outlined in 2.6.4, "Trust Association with
WebSEAL" on page 40, the WebSphere Member Manager component of WebSphere Portal
Server must perform an addition LDAP query to retrieve a further number of user attributes
and to determine the group membership for the concerned user.

2.6.6 Other Tivoli Access Manager considerations

The following recommendations are made with respect to integrating Tivoli Access Manager
V6.0, both the Policy Server and WebSEAL components, with WebSphere Portal Server
V6.0.1.
WebSphere Portal Server login with Tivoli WebSEAL
Most WebSphere Portal Server deployments include a number of anonymously accessible
Portal pages. Advanced configurations may even see the default Portal Login page replaced
with a Login Portlet. When WebSphere Portal Server is used in conjuction with Tivoli Access
Manager, special consideration needs to be exercised to ensure that both products work in
unison.
By default, the standard WebSEAL configuration is to intercept each new client request and to
challenge a user to sign-in against a login form before accessing, through a proxy, the actual
requested content. Unfortunately, what is not clearly documented in many publications is that
this login form is actually the WebSEAL login page. Furthermore, unlike a WebSphere Portal
Server page, the WebSEAL page is only capable of supporting static HTML content.
Potentially, this page could be customized to mimic the same look and feel as the Portal.
However, this may then lead to inconsistencies if WebSEAL is deployed as an enterprise wide
security solution.
An alternative approach to the above would be to configure WebSEAL to allow
unauthenticated requests to reach, through a proxy, the anonymous pages of WebSphere
Portal Server. In this manner, it would be possible to use WebSphere Portal Server to display
dynamic Portlet based anonymous content. A user could also interact with a Login Portlet
when attempting to register and authenticate him or herself into the solution. In such a
situation, the Login Portlet would simply post the supplied user ID/password to the WebSEAL
pkmslogin Servlet. The post command may, or may not, include a string containing the URL
of the page to redirect to after successful authentication.
Chapter 2. Architecture and planning
41