We are finding the exceptions "SESN0008E: A user authenticated as anonymous has attempted to access a session owned by user:" In our SystemOut.log for WebSphere Application Server. Can these exceptions be disabled? What isthe cause of these exceptions? Please advise.
Following exceptions are thrown by WebSphere Application Server session manager when an "Anonymous" user tries to access a session that is owned by a secured user(The user who created the session).
ESN0008E: A user authenticated as anonymous has attempted to access a session owned by user:abcd-123 at com.ibm.ws.session.SessionContext.checkSecurity (SessionContext.java:1358) at com.ibm.ws.session.SessionContext.isValid(SessionContext. java:877) at com.ibm.ws.webcontainer.srt.SRTRequestContext.getSession (SRTRequestContext.java:95) at com.ibm.ws.webcontainer.srt.SRTServletRequest.getSession ######
Session hijacking is a known attack, starting from WebSphere Application Server V8.0 WebSphere has tightened the session security by enabling the "Security Integration" by default. Enabling this option would prevent hijacking of the HTTP sessions if all the requests going over the network are enforced to be over a secure connection. If the application is not coded to use this feature, disabling "Security Integration" check box would eliminate above mentioned exceptions. Navigate to the following location to disable the option.
Servers > Server Types > WebSphere application servers > server_name > Session management.
Varun answer is only partially correct. The message can be reason of session hijacking, but more commonly it is result of mixing in the application pages which are protected by security constraints and these available by anonymous users. Once the user is authenticated, the session becomes connected to that authenticated user. When same user access unprotected page, his credentials may not be passed and is treated as unauthenticated - creating these errors.
So my suggestion would be to check if the
Global security > Web security - General settings page you have enabled setting
Use available authentication data when an unprotected URI is accessed.
This will be better solution than disabling Session security integration, as it will probably solve your issue, allowing mixed (unprotected and protected) pages to access session and also prevent session hijacking - accessing sessions by completely unauthenticated user.
Just to add, below is my explanation of the issue:
The error is sometimes caused by the LTPA timeout occurring before the session timeout. You can increase LTPA timeout to help this, or you can try disabling session security integration which some applications need to work properly.
In other words, generally this error occurs when the LTPA token expires but the session is not expired. If you don't want to integrate security support for the session you can disable it.
In the IBM Websphere Administrative Console navigate to Applications->Websphere Enterprise Applications -> app_name -> Session Management
Check the Override session Management checkbox
Uncheck the Security integration option, save, sync and restart nodes to test.
Alternatively, you may want to check this link for other options:
"IBM Security Cache, LTPA Token, and Session Time Outs"
The application should handle this by asking the user to login again, depending on what method of authentication is being used.
By default the LTPA token lasts only 2 hours. So another option is to increase the LTPA timeout duration.
IBM Knowledge Center:
From WAS 8.0 onwards this check box is checked by default. Where as this check box was un-checked by default in older versions of WAS. Please uncheck that check box, save the changes and then restart the servers to see if you are able to login.
Then check the systemOut.log to verify if the error is received or not.
Both answers from Varun and gas are only partially correct. Even if you activated
Use available authentication data when an unprotected URI is accessed the SESN0008E error does not disappear in all cases. Muhammad-Khan is right that the LTPA Token timeout affects the occurence of the error. E. g. in one case, I observed that increasing the LTPA Token timeout from 2 to 12 hours the number of occurences of SESN0008E errors decreased from ~450 down to ~2 per day.
However, increasing LTPA Token timeout is mere symptom suppression. The root cause are bugs in the CDI implementation of WebSphere. Looks like IBM took a CDI implementation that does not properly handle the situations where LTPA Token timeouts occur. E. g. http://www-01.ibm.com/support/docview.wss?uid=swg1PM97228 which was fixed in 184.108.40.206. However, I currently investigate a strikingly similar problem in 220.127.116.11 in another Class (JCDIWebListener) with almost the same symptoms.