Using Security Session IDs for Single Sign-On Between Applications 

Per default, the standard JSESSIONID mechanism is used to exchange the information about the user’s identity between the Web applications when performing single sign-on. It is based on the associations between the HTTP sessions of the user established for the different applications, and the security session that is established after the user logs in to an application. This information is sent with the HTTP request using a session cookie (or URL rewriting, if cookies are disabled). The name of the cookie used for this purpose is JSESSIONID.

If the client does not accept cookies, then the server can use URL rewriting for this session tracking, which adds the session ID to the URL path. This ID is interpreted by the container to associate the request with the session. The session ID is encoded as a path parameter (JSESSIONID) in the string of the URL.

http://www.example_server.com/test/index.html;JSESSIONID=0123

Single sign-on using the JSESSIONID mechanism is only possible between applications that are running on the same server process in the cluster. This is because the security sessions created to identify the user’s security identity are not persistent, and therefore cannot be migrated to another server process.

See also:

·        J2EE Engine Cookies in the Development Manual

·        Security Sessions

·        The Java Servlet Specification Version 2.3