The SESN0008E error can appear when session security integration is enabled (default behavior). This error is observed in the SystemOut.log file when a user attempts to access an HTTP session with a web request, but the session is associated with another user account. For example, if sampleUser_A determined the value of sampleUser_B's JSESSIONID cookie, and then loaded a web page with sampleUser_B's JSESSIONID, the request would fail with the following error.
SESN0008E: A user authenticated as <sampleUser_A> has attempted to access a session owned by <sampleUser_B>.
The JSESSIONID cookie contains an opaque value that points to some HTTP session data stored in-memory on the WebSphere Application Server. The JSESSIONID cookie is created when a web application calls HttpServletRequest.getSession() on an HttpServletRequest that does not have an existing in-memory session and its corresponding JSESSIONID cookie. The web application can then store arbitrary data within the in-memory session. When a request arrives with a JSESSIONID cookie, the web application can load and use the session data.
In general, web developers use sessions to store information about the state of the web app relative to the client that owns the corresponding JSESSIONID cookie. One common example of a web application's use of session data is a storefront that uses a shopping cart.
To investigate the error, we need to determine how the user got into a state where they were able to access another user's session.
Scenario 1:
SampleUser_B's credential, such as an LTPA token, expired while they were using the application. The next request will be as an unauthenticated client to a login page, which typically is not protected by any security-constraint defined in the application's web.xml. This series of events can result in the user's access of a session owned by the "unauthenticated" account.
Scenario 2:
Some applications can be designed in a way that prevents the Session Security Integration feature from being viable. For example, if the application's unprotected form login page requires session information it can cause issues as users need to access that page to authenticate. In this situation, it might be necessary to disable the Session Security Integration feature.
Scenario 3:
SampleUser_A gets ahold of sampleUser_B's JSESSIONID value and uses it to try to access the session data of sampleUserB.
The best-practice recommendation to resolve this scenario is to define a security-constraint for the requested resource in the web application's deployment descriptor. To protect the JSESSIONID cookie, consider enabling the HttpOnly and Secure attributes.
[{"Type":"MASTER","Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"ARM Category":[{"code":"a8m50000000CcxxAAC","label":"WebSphere Application Server traditional-All Platforms-\u003ESecurity"}],"ARM Case Number":"TS012368792","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]