The Session invalidating is the standard mechanism in J2EE to logout. However, the session is probably cached in the browser and has really not logged out. So, we are advised to use ibm_security_logout after Websphere 6. This becomes vendor specific. Can you suggest a J2EE solution for Websphere for reliable logout.
The session data is never stored on the client. Only the session ID, which is simply a mystically-generated hashkey with no inherent meaning. When you invalidate the session, that particular key is deleted from the server's sessions collection, making it useless thereafter.
What benefit you get from IBM's little quirk isn't clearly explained in any of the documentation that a casual search turned up. It does allow you to define a logout page without the need to actually implement logout code in your web application, but other than that, I can't tell.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Oct 08, 2002
My predecessor has entered the ibm_security_logout as a quick way of out of single sign on. Websphere has a default option for SSO. It uses a cookie called LTPA for SSO. The ibm_security_logout (I think) deletes LTPA cookie. Once the LTPA cookie is removed from the browser cache, the logout is successful.
The session.invalidate does not remove the cookie, for the right reason. Because the SSO cookie is valid for other Web components of the same EAR.
I think the best way is to disable SSO. My attempts to disable resulted in inability to login to websphere admin console or inability to FORM login to web components of EAR. I can't believe that SSO cannot be disabled. The reason is Websphere has a checkbox to disable. They would have provided a checkbox for a good reason. Is there a right way to disable to SSO for Form login?
Ugh. That's bad in 2 different ways. First, it only does SSO for IBM products and products written to act like IBM products. True SSO doesn't have that restriction.
Secondly, by passing the SSO token around the network, it exposes it to possible hijacking and exploitation - as you have noted. Most SSO systems keep their tokens behind the servers, not in front of them.
You should be able to portably "log off" LTPA by deleting the LTPA cookie from the response stream of the servlet that is doing the session invalidate. That won't in and of itself purge any additional server-side constructs relating to the IBM SSO, but at least it makes it possible to remove the cookie from active play.