Clear or refresh the credentials cache?

[David O'Meara]

We're having a problem with form-based authentication in WAS 4.0.2 and LDAP (ie LTPA token authentication usinf SecureWay) where WS appears to be caching authentication credentials.
Scenario:
A user visits the site and registers.
After a while they decide to deregister. (At the back-end, this involves removing them from the required role and deleting the LDAP data)
The problem is, the user can still login to the site!
It appears the WS is holding onto the username/password and not releasing it when the data is deleted and not noticing the change.
Anyone know where this data is being held, know where the property settigns are or a way to implicitly or explicitly clear or update this cache?
ta,
Dave
(as an interesting secondary effect, the password is updated in the cache when he back-end is updated, but it didn't work when we tried changing the password before degregistration to stop the user from logging back in)

[Devan Lipsey]

One of the developers on our team had a similar problem... Go to this post to see the resolution:
http://groups.google.com/groups?q=colby+brown+group:ibm.software.websphere.application-server.*&hl=en&lr=&ie=UTF-8&selm=72a2c606.0208080938.57264b1e%40posting.google.com&rnum=1

[David O'Meara]

No, not the problem I'm having.
I'm doing everything in the link you gave to log the user out and that much is OK.
The difference is that a deregistered user can still log in since WS appears to hold the authentication details.
Still keen to hear from anyone who can help.
Dave

[Devan Lipsey]

Sorry that didn't help... There is a security cache timeout setting that can be changed from the security console. You could set this to a low number to see if the server is truly returning to LDAP to get the latest information for caching. This mechanism seems to have trouble on the version we are running (4.03 on AIX), but you could try it...

[David O'Meara]

Don't get me started on that particular value.
(Too late)
There's a session timeout in web apps that can be set at a global level or on a per-application basis and that works well.
Then IBM decided to implement LTPA tokens completely differently and give it its own timeout value.
Fine I can live with that. But it gets worse.
This timeout value appears to be absolute. As in if you set it to 5 minutes, a person gets logged out after 5 minutes regardless of their activities.
The other (other) stupid/confusing thing is that if the session times out and the security doesn't, WS just hands out another session ID. Imagine how confusing and difficult to track that can be if you're using sessions.
We got around this wierd behaviour by setting the LTPA timeout to 15minutes and the session timeout to a value larger than this.
rant finishes here--------------

[JeanLouis Marechaux]

Some info I had from IBM.
1) There no way to flush the cash manually (with an API or whatever.)
This will never exist in WAS 4
This does not exist in WAS 5
2) WebSphere have a cache for the credentials, refreshed according to the Security Cache Timeout.
When a credential is modified (removed or updated)
it takes was 1.5 times the security cache to disappear.
Sides effects :
A deleted user can log in as long as the cache timeout is not reached and the LTPA Token is not expired.
If a password change, a user can logon with the old OR new password, till the old one is flushed from the cache or the LTPA Token expire
The LTPA Token is an absolute value.
The Security Cache Timeout is relative to the last
time a specific entry is accessed in the security cache
Conclusion...works as designed
[ September 17, 2002: Message edited by: Bill Bailey ]