ShowTable of Contents
Authentication session and http session
Http is a stateless protocol. Now Web Applications and Application servers did extend this protocol using tokens to identify interaction sessions and so be able to provide a broader set of functions. Two well known concepts are the Http Session
and Authentication Session
Technically both conceps are independend from each other, but practically they belong to each other. While the Authentication session keeps track about the user and its identification state the Http Session does only build a relationship between a server side "cache container" and the browser instance. One important part to keep in mind is the lifetime or pattern behind these two concepts. Http Session usually bases on an activity pattern. As long as the user is working with the Application the token lifetime is refreshed. Authentication Sessions tend to start with a fixed lifetime to minimize the impact if a token is stolen.
As an example I will take WebSphere Application Server. The build in authentication Token (Ltpa and Ltpa2) are created on a fixed verification time, which is enforced client and server side. The HttpSession does have an activity timeout of 30 minutes. For an end user this means 30 minutes of inactivity will destroy its server side data, but he would still be recognized as the authenticated user. Now we come to the general problem. Many people forget to logout or to destory their authentication session. Which leads to the point of having a valid token lingering in the browser and someone perform actions as this user just by using the same browser window. An activity based Authentication session would help here and reduce the attack or missuse window.
WebSphere as is does not claim this function, but there had been several attempt to provide help for certain usecases. One of these attempts is a property named com.ibm.ws.security.web.logoutOnHTTPSessionExpire.
Functionality of com.ibm.ws.security.web.logoutOnHTTPSessionExpire
This property ( details ) can be set at WebSphere Application server since 6.0. The function it provides is targeted for a single WebApplication scenario. In this scope it does verify if an incomming JSessionID is matching a session already existing for the current WebApplication. If there is no session found, but a valid Authentication token WebSphere will revoke the authentication token and send the user to an authentication page. The intend behind this behaviour is to invalidate the Authentication in case of an expired Session. Within a single WebApplication this works as the Application itself is responsible for creating the session and only if it created a session this session could be available on a follow on incomming request.
This is different if there are multiple WebApplications working together either via CORS or browser integration or simply by sharing the same Https Session Cookie domain.
Impact on WebSphere Portal
As WebSphere Portal is a combination of multiple WebApplications it is important for us to preserve SSO between these different WebApplication independent if one of them requires a Http Sessions and others not. With this said it is not possible for WebSphere Portal to support this configuration without a functional lost. In cases of setups without an Authentication Proxy we recommend to use the WebSphere Portal own solution to bind the HttpSession to the Authentication Session. If you have an Authentication Proxy configured and responsible for protecting WebSphere Portal the function to provide an activity based Authentication Session is required by this Authentication Proxy and not from WebSphere or WebSphere Portal