The following information applies to WebSphere 4.0 (and maybe 5.0) but perhaps it may also shed some light on the situation with Tomcat.
In WebSphere , you can specify to use LTPA Lightweight Third=Party Authentication). Then successful authentication stores an LTPA cookie in your browser. You can set the expiry period for the LTPA token.
The following IBM FAQ explains in more detail for WAS. It also says that if you use LocalOS authentication, rather than LTPA, then you can get a timeout effect by setting a session timeout.
Regards,
Don ==========================================
FAQ on Security Cache, LTPA Token timeout , and session timeouts Frequently asked questions
Question FAQ on Security Cache, LTPA Token timeout , and session timeouts
Answer
Q1. What happens when the Security Cache times out? Will the user be asked to relogin?
A1. No. When using SSO, the Security Cache will refresh from the LTPA Token. If your LTPA Token is also expired, then the user will be asked to re-login.
Also, the cache timeout period is reset every time that entry is hit. So, if the entry is hit 9 minutes into the 10 minute timeout period, the clock is reset at that time. So, instead of timing out in another minute, it is now reset for another 10 minutes, then if it's hit again in that time, it will get extended again.
When using Local OS for authentication, the user will be asked to login when the session times out, not the security cache.
Q2. 1 - Using a browser, we accessed a secured application, we provided the UserID (UserA) and a valid PW (Password1). A token was
created. So far everything is working fine.
2 - We manually changed the password for UserA in the LTPA (LDAP or custom registry) from Password1 to Password2.
3 - Using a new browser we accessed the application providing UserA
and the new password (Password2) a token was created and again
everything is working as expected.
4 - Using a another new browser we accessed the application providing
UserA and the old password (Password1). We were so surprised to
noticed that a token was created and UserA was able to access
the application!
A2. This is working as designed. The old password takes up to
1.5 times the security cache to disappear. It will also expire at the end of the LTPA token timeout. There is not a way to manually purge the cache at this time. There is a mechanism available to disable the cache, but this is not recommended for performance reasons.
Q3. I want to force my users to re-login after a set "inactivity timeout" period. How is WebSphere supposed to work with regard to session timeouts and LTPA timeouts?
A3. Essentially, the problem lies in that WebSphere implements Single Sign
On (SSO) which uses the LTPAToken cookie to store its information. This
causes a failure to relogin when the session times out. Since this
isn't part of the J2EE specifications, it lies outside of the
requirement to force a relogin when the session times out. Disabling SSO
would eliminate the LTPAToken cookie from being sent to the web browser,
but it has adverse side effects in performance and there will most
likely be forced logins at inappropriate times or
authentication/authorization failures. One way to avoid this is to use
Local OS instead of LTPA as the authentication mechanism. Local OS uses
the session rather than a separate LTPAToken cookie, so when the session
times out, the user is also forced to login. However, local OS has
limitations as described in the InfoCenter. It is meant to be used for
only one WebSphere node and application server process. Multiple WebSphere nodes or application server processes sharing the same repository database can't
use local OS.
Q4. If this is the case, can we expire or delete the LTPAToken cookie when the session expires? If so, what mechanism should we use?
A4.You can manually perform a form-based logout (as described in the InfoCenter) to request that the LTPAToken cookie be destroyed in the web browser, but within WebSphere, there is no functionality to automatically perform the form-based logout when the session times out. This would have to be performed programmatically if it is possible at all. This is out of the domain of WebSphere support and falls into the consulting category. If you wish this functionality of invalidating LTPA-based authentication login when the session times out to be considered in a future release of WebSphere, please contact you IBM Marketing Representative and have him or her submit this as requirement.
_______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
