I'm working on a web application and I've run into an issue. I have secured the page "index.html" in my web application. Here's a snippet from my deployment descriptor:
This seems to work fine, initially. When I try to access index.html, I'm redirected to the login page. From there, I can log in to the application.
The problem really occurs when a user tries to log out or the user's session times out. When that happens, I send the user to a "logged out" page or a "session timed out" page. From there, I have a link so that the user can easily log back in to the application by going back to index.html.
The problem is that, when the user goes back to index.html, the user is not forced to authenticate again. Instead, the user goes right in to that page. Without authentication, I have no idea who the user is (their data is stored in the session) and I get errors from my web app when the user tries to access it.
Once the session expires (or is invalidated via "request.getSession().invalidate()"), shouldn't the user be forced to authenticate to any secured resources once again? I thought that was the case, but it doesn't seem to be.
Corey, There are multiple timeouts involved. There is the session timeout which is the one you are discussing. There is also a WebSphere timeout for WAS authentication. If you are using a third party tool like Siteminder or Netegrity, they have their own logout timeouts too.
Check to see that all of these are set to the same value. If one is more than the others, you run into a situation similar to the one you are describing.
Corey, When logging a user out, you should do three things: 1) destroy HttpSession - session.invalidate() 2) Null out invocation credentials - new ServerSideAuthenticator().setInvocationCredentials(null); 3) If using SSO, unset SSO cookie - new SSOAuthenticator().logout(req, res);
The WebSphere timeout for WAS authentication is in the admin console under the server. If I time today, I'll try to be more precise.
author & internet detective
Corey, Security --> Authentication Mechanisms --> LTPA. The fourth item down is the timeout I was referring to. It makes sense that this would be global to all servers.
"The time period in minutes at which an LTPA token will expire. This time period should be longer than cache timeout configured in the Global Security panel. "
It's the server that has an option to override the cache timeout (Servers --> Application Servers --> <App Server Name> --> Server Security -> Server Level Security) This one is also set in the global security defaults. As long as it is less than the LTPA timeout, it wouldn't be the cause of the problem.
Joined: Dec 20, 2001
Thanks, Jeanne - that all works great.
I'm still having just one problem. If the user opts to log out prior to their timeout, how do I get rid of the LtpaToken cookie? When the user goes beyond the Ltpa timeout interval, that cookie is expired and causes the user to have to reauthenticate. But, how I do expire that cookie explicitly when the user chooses to log out, rather than being timed out?
I've tried expiring it in my Java code, like this:
That sets the max age to 0 successfully, but the cookie doesn't seem to actually expire, as I'd expect it to.
author & internet detective