Question 1
What happens when the Security Cache times out? Will the user be asked to
re-login?
Answer 1
No. When using single sign-on (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.
Be aware that in V6.1, the Federated Repository has it's own cache
settings. See the link under Related Information.
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
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.
In IBM® WebSphere® Application Server V5.0.2 and later, you can purge a
user from the security cache using an MBean interface. See the Related
Information at the end of this article.
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 timeout.
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.
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.
|