4

In our vaadin web application we get an UnauthorizedSessionRequestException when the LTPA token expires. The application is not responding anymore after that. The LTPA token expires even if the session is not inactive and the user does seomething. The LTPA token timeout on our production server is set to 120 Minutes. But I can test it on my local machine also with a timeout of 1 Minute in my Web Sphere Liberty Profile to comprehend the problem.

This is the stack trace of the exception in german:

[ERROR   ] SESN0008E: Ein als anonymous authentifizierter Benutzer hat versucht, auf eine Sitzung zuzugreifen, deren Eigner user:BasicRegistry/ksc ist.
[ERROR   ] SRVE0777E: Es wurde eine Ausnahme von der Anwendungsklasse 'com.vaadin.server.VaadinServlet.service:240' ausgelöst.
javax.servlet.ServletException: com.vaadin.server.ServiceException: com.ibm.websphere.servlet.session.UnauthorizedSessionRequestException: SESN0008E: Ein als anonymous authentifizierter Benutzer hat versucht, auf eine Sitzung zuzugreifen, deren Eigner user:BasicRegistry/ksc ist.
    at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:240)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1240)
    at [internal classes]

In english

A user authenticated as anonymous has attempted to access a session owned by user
ﾤ ﾡ
  • 5,669
  • 6
  • 43
  • 57
ResidentSleeper
  • 93
  • 1
  • 7

2 Answers2

3

The LTPA token works quite differently from a session.

When a LTPA token gets created it will be valid for a certain time, set in the LTPA token timeout (in your case 120 minutes). While a session timeout gets prolonged on every request you make the server, the LTPA token timeout does not. The token will keep its original timeout time even when subsequent requests are made to the server.

There is another setting controlling when a LTPA token should be extended. This setting is called cacheCushionMax and its default value is three minutes. What this means is that the LTPA token will only get refreshed on a request if there is less time left than this value. If there is more than three minutes to go before the LTPA token expires, it will keep its old timeout time.

To change this value:

  1. navigate to the custom properties section of the Java Virtual Machine (must be repeated for each server in a cluster)
  2. Create (or edit if it exists) a property named com.ibm.ws.security.cacheCushionMax with the value you would like (in minutes). The cacheCushionMax value cannot be larger than 1/5 of the LTPA timeout value.

The best resource I have found about this is on an IBM support page. It is old but still valid. What I have written is also explained in more detailed scenarios, look especially under the section "Minimum effective expiration possible"

ﾤ ﾡ
  • 5,669
  • 6
  • 43
  • 57
DanielBarbarian
  • 5,093
  • 12
  • 35
  • 44
  • 1
    Do you know of any more graceful way to handle this exception in application? It seems that you should be prompted for credentials or asked to re-authenticate rather than kicked out of the application with a low-level error message which forces the user to close the browser to start a new session. – ammianus May 30 '14 at 13:59
  • If you are not authorized in any way, then yes, you should be prompted for a relogin, but that does not only depend on the WAS container, but also on the application involved. Since I don't know enough about vaadin I wouldn't know for sure. How is the login done the first time you access the application? – DanielBarbarian Jun 02 '14 at 15:20
  • My application is not vaadin but I came across this question as we had the same problem. In my case we have a web application that is "unprotected" in the sense of WebSphere security, and a new "protected" set of RESTful services on the same server. The web application has it's own login form and internal authentication. We are authenticating with the RESTful services using a request from the login page that sends a Basic authorization header and the client gets the LtpaToken2 cookie which get's used for subsequent requests. We get this issue navigating around the web app after being idle. – ammianus Jun 03 '14 at 16:44
  • Ah, and that could also possibly explain a few things. If you would have had an application that is protected using Java Security requiring authentication, then WAS will sense that you are trying to access a page where authentication is required while you are not authenticated (because of a new login, timeout or so). That will make the WAS container trigger a login. – DanielBarbarian Jun 04 '14 at 05:57
  • If the application is not protected through standard Java Security mechanisms, that may actually also have effect on how the LTPA token is renewed, but that is more of a guess. – DanielBarbarian Jun 04 '14 at 05:59
  • @DanielBarbarian I doubt there is such thing as "LTPA token extension" as concerns web applications. You referred to the page that describes LTPA token behavior in specific environment (Process Server) where it makes sense. I am not aware of any facility that can prolong the timeout of LTPA token used by web application. – ﾤ ﾡ Jun 14 '15 at 17:39
  • @fnt That depends a whole lot on what you want to put into the "LTPA token extension" expression. It is true that I have linked to a WebSphere Process Server page, but that is because I have not found it better described anywhere else. The LTPA token mechanism is part of WAS technology, which WebSphere Process Server and others rely on. I have successfully used these settings in a non-WebSphere Process Server setup. Here is a page of cacheCushionMax for a WAS version: http://www-01.ibm.com/support/knowledgecenter/SS7JFU_8.5.5/com.ibm.websphere.zseries.doc/ae/csec_ltpa_token.html – DanielBarbarian Jun 15 '15 at 05:57
  • @DanielBarbarian I basically used your terminology, quoting: "There is another setting controlling when a LTPA token should be extended". For now I can only understand "extension" as the procedure that prevents expiration of LTPA token by extending its timeout. Effectively this should remove the need for user to re-authenticate. I am eager to see how this could work in practice. I perfectly understand that "cushion period" is WAS setting, the thing obscure to me is how it can help with the problem in question, i.e. expired LTPA token and alive HTTP session. – ﾤ ﾡ Jun 18 '15 at 16:37
0

looks for me as if the URI is not protected within WebSphere. There had been some changes on the WebSphere defaults. I expect the configuration tells WebSphere to establish a security context as soon as an LTPAToken is available, even on unprotected URL's. In this case unprotected URL's will get the security context as if they would have been using a security_constraint defined in Web.xml. If now the LTPA token is invalidated and the HTTPSession is still valid (remember HTTPSession is activity based vs LTPA token fixed time) WebSphere does now see a violation in accessing the Session. This had been added to prevent session highjacking attacks. You can disable this function and there are some custom properties on the HTTP container. I would not recommend to turn it off, but more rethink if your application should be accessible for authenticated and non authenticated users using the same context/servlet path

Stefan Schmitt
  • 165
  • 9