SSL ID
To use the SSL ID as the session modifier, clients need to be using an SSL connection to the Web server. This connection does not need to use client certificate authentication, but simply a normal server authentication connection. This can be enabled by turning on SSL support in the Web server. The steps for doing this are detailed in the redbook IBM WebSphere V5.0 Security, SG24-6573.
The session ID is generated from the SSL session information. This is passed to the Web server and then passed on to the plug-in. If more than one Web server is being used, then affinity must be maintained to the correct Web server, since the session ID is defined by the connection between browser and Web server. Connecting to another Web server will reset the SSL connection and a new session ID will be generated.
SSL tracking is supported only for the IBM HTTP Server and SUN ONE Web Server.
It is possible to maintain the SSL session affinity using the Load Balancer from IBM WebSphere Edge Components. See 4.5.5, SSL session ID for details.
SSL session ID cannot be used on its own in a clustered environment. It is not possible to add the cluster member ID to the end of the SSL session information, so another mechanism must be used. Either cookies or URL rewriting needs to be enabled to provide this function. The cookie or rewritten URL then contains session affinity information that enables the Web server to properly route requests back to the same server once the HTTP session has been created on a server. If cookies or URL rewriting are not enabled, then a session will be created but there will be no mechanism to return the user to the correct cluster member at their next request.
The format of the cookie or URL rewrite is shown in Example 5-9.
Example 5-9 Affinity information format when using SSL
SSLJSESSION=0000SESSIONMANAGEMENTAFFINI:v544d0o0
This is the same format as described in Example 5-7 but in place of the session ID is the word SESSIONMANAGEMENTAFFINI.
With SSL, the session timeout is not controlled by the appserver. The session timeout delay is governed by the Web server and the Web browser. The lifetime of an SSL session ID can be controlled by configuration options in the Web server.
When to use SSL ID
When using a clustered environment, SSL ID requires a lot of overhead to set up the infrastructure. There is also a single point of failure for each session: the Web server. If the Web server goes down, the user will lose the session ID and therefore access to session information.
SSL ID will also be slower than other mechanisms, since the browser has to communicate using HTTPS and not HTTP. The inconsistency of browsers and their SSL handling could also affect how the application performs.
However, SSL provides a more secure mechanism of user identification for session information. The session identifier is difficult to copy.
If your Web site requires the highest security, then use SSL ID, but be aware that it comes with the overheads and deficiencies mentioned above. Consider using standard cookies over an SSL session instead.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.