IBM BS029ML - WebSphere Portal Server Self Help Manual page 56

WebSEAL high availability
The failure or outage, either scheduled or unscheduled, of a WebSEAL server will result in the
need for a user to re-authenticate unless a suitable mechanism is configured to handle such
conditions. Load balancer affinity normally ensures that subsequent requests from a client go
to the same WebSEAL server for enhanced performance. However, when a WebSEAL server
fails, the Load Balancer will redirect the user's request to the next available WebSEAL server.
However, the WebSEAL-to-user session is maintained on an individual WebSEAL cache
basis and when one such WebSEAL goes down, all other WebSEAL servers treat this as a
new request and require re-authentication to be done by the user.
To overcome these issues, and to achieve seamless failover between multiple WebSEAL
server, one of two mechanisms can be deployed:
The Failover Cookie approach is a mechanism by which an additional cookie is created
(and updated every time) and sent by WebSEAL during authentication to the user. When a
request is failed over to another WebSEAL server, that server decrypts the cookie to
understand that the user was a pre-authenticated against the initial WebSEAL server.
The Session Management Server, newly introduced in TAM V6.0, is a useful alternative for
maintaining the failover sessions of WebSEAL in a persistent manner. As such, the
Session Management Server exposes a Web service to persist the user sessions to a
database.
WebSEAL load balancing
WebSEAL includes the built-in capability for providing load balancing and failover when two or
more back-end systems participate in the same junction definition. However, it is important to
recognize that such a configuration does not extend to gracefully quiescing user requests,
from one or more back-end systems, when those systems need to be taken down for
scheduled maintenance. This is in contrast to the feature rich functionality provided by most
commercially available load balancers. The requirement to be able to gracefully quiesce
users, from one or more back-end systems, is especially important when deploying a dual
clustered WebSphere Portal Server architecture with Two Lines of Production.
Session Management Server
The Session Management Server, as discussed previously in "WebSEAL high availability" on
page 42, is a newly introduced feature of Tivoli Access Manager V6. In addition to the ability
to handle session failover between multiple WebSEAL servers, the Session Management
Server can also be deployed to restrict the number of concurrent logins or sessions each user
can have at one time. Such a requirement is often in demand when WebSphere Portal Server
is deployed in the Financial Services sector.
However, using the Session Management Server requires additional resources, as the
component runs as a WebSphere Application Server based application. Furthermore, at the
current time of the writing this document, the Session Management Server does not support
any database server other than DB2.
Common Auditing and Reporting Service (CARS)
Tivoli Access Manager Version 6 also includes the new IBM Common Auditing and Reporting
Service (CARS) platform, which provides a consistent way to collect audit events and report
on the collected data. However, like the newly included Session Management Server, the
CARS event server also demands consideration during the early stages of a project, as the
component also runs as a WebSphere Application Server based application. Likewise, at the
current time of the writing this document, the component only supports DB2 for data storage.
42
IBM WebSphere Portal V6 Self Help Guide