Question 1
What happens when the Security Cache times out? Will the user be asked to
re-login?
Answer 1
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.
Question 2
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!
Answer 2
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.
Question 3
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 time.
Answer 3
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.
Question 4
If this is the case, can we expire or delete the LTPAToken cookie when
the session expires? If so, what mechanism should we use?
Answer 4
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.
|