Websphere Security Caching

[JeanLouis Marechaux]

Hi folks,
Please first allow me to explain what we are trying to do.
Using WAS 4 with Custom registry LTPA and a DB for security, we want to give users the ability to chamge their password, with a web interface.
But, as WAS caches security informations, when the user changes the password, this modification is ignored while :
1 - the security cache timeout occurs
2 - or the admin server is restarted.
I'm sure you understand 2) is not a solution.
And 1) is not a good one. If we set the cache timeout to 0, then the user has to log in again each time he performs a request.
This is weird ! Is there another way to tell WAS he has to refresh the credentials in its cache ??
Any thought is appreciated

[Simon Song]

I guess you are relying on SSO to authenticate the user. In our case, SSO is not a necessary feature. So we just use ServerSideAuthenticator to authenticate user, and put the credentials in the Session(not in cookie). When user changes password, he is still authenticated.
With SSO enabled, you may have to use SSOAuthenticator logoff this user programmatically, and relogin with new password to generate the right SSO Coockie.
So inside your changePassword() routine, you logoff/login.

[JeanLouis Marechaux]

yes we are relying on SSo because we use Fom Login and WebSphere only accepts Formed Based Authentication with SSO.

Simon, I don't really understand your point.
My understanding is that the credentals are cached, with our without SSO.
So if User1 is associated with Password1 in the cache, then the new paasword you enter is not taken into acount until the cache is flushed.
(and I don't know hen the cache is flushed...but that's another problem)

[Simon Song]

When you use SSOAuthenticator to logout user, I think WAS should clean up the cache(maybe SSO coockie).
You have to study what SSOAuthenticator class can offer now, find API doc in the InfoCenter.
Relying on J2ee form based authentication is just okay, it simplify your coding but you lost control to the container. If you want to control soemthing, you must dig out the container API and do it by yourself...

[Kyle Brown]

This is an interesting problem. I've never thought of trying to change the password live like this.
Could you redirect to a form logout page? (http://www.ibm.com/software/webservers/appserv/doc/v40/aee/wasa_content/050403.html) If that doesn't work maybe you could try deleting the LTPA cookie?

[David O'Meara]

Hmm, similar but strangely different to the problem we are having with LTPA and form based authentication involving caching.
https://coderanch.com/t/71921/Websphere/Clear-or-refresh-credentials-cache
Interesting that our change password functionality is the bit tha works though

[JeanLouis Marechaux]

Ok guys.
Thanks for your answers.
I gonna try to answer to each of you.
But I don't really understand how the credential caching works, so please forgive me if some explanations are unclear.
Simon/Kyle, do you mean all the problems I have can be solved erasing the SSO token ? Is it because there's SSO token that WAS caches the credentials ?
Simon : I did a search on SSOAuthenticator in infocenter and it only returns topic 5.3, which does not really help.... It only specified SSOAuthenticator is deprecated ???
Kyle No I can't redirect to a form logout... but if I can do it programmatically as Simon suggested, then maybe it could help.
David : Same kind of problem. In your thread, you pinpoint a problem I also wanted to talk about. Is the timeout absolute or depending on activity. I'm unable to find an answer yet....
To all: I don't really understand the internal WAS behavior. What is the differences between the Security cache timeout (Security/General tab)and the LTPA Token Expiration (Security/Authentication tab).
The Change Password sample I gave was just a simple one.
But I think there are other scenario where the credentials caching could be a problem.
I think David also experienced this one.
A user belongs to a group, mapped to a J2EE role.
The first time the user logs in, the credentials (user, passwd, groups)are loaded in memory.
If the administrator of the LDAP changes groups, WAS does not take care because everything is in memory...
To workaround this problem, we tried to decrease the Security cache timeout to 30 seconds. We thought it could allows to refresh the credential as needed.
Yes it does, but it challanges the user for its login and password information each 30 seconds .
Maybe it could have been better just refreshing the data from the LTPA source without asking the user for it, no ???
[ September 03, 2002: Message edited by: Bill Bailey ]

[JeanLouis Marechaux]

Some piece of information about WebSphere caching from the IBM Lab.

  
DISABLING THE AUTHENTICATION AND VALIDATION CACHE
.
To disable the Admin Server authentication and validation caches, the
following system properties should be set in the admin.config:
.
 com.ibm.websphere.security.util.LTPAAuthCacheEnabled=false
 com.ibm.websphere.security.util.LTPATokenCacheEnabled=false
.
To disable the Application Server authentication and validation caches,
the following system properites should be set on the Command Line field
for each application server where the cache is being disabled:
.
-Dcom.ibm.websphere.security.util.LTPAValidationCacheEnabled=false
-Dcom.ibm.websphere.security.util.CredentialCacheEnabled=false
.
Either remove these entries or set them to true to enable the cache
again.
.
SHOWING PERFORMANCE IMPACTS
.
Two other system properties were added to help determine the performance
hit which you will see when disabling the cache.
.
To enable timing the authentication and validation that occurs at the
Admin Server, the following system properties should be set in the
admin.config:
.
 com.ibm.websphere.security.util.AuthenticationTimingEnabled=true
 com.ibm.websphere.security.util.ValidationTimingEnabled=true
.
To enable timing the authentication and validation that occurs at the
Application Servers, the following system properties should be set on
the Command Line fied for each Application Server where showing the
timings is desired:
.
-Dcom.ibm.websphere.security.util.AuthenticationTimingEnabled=true
-Dcom.ibm.websphere.security.util.ValidationTimingEnabled=true
.
Restart WebSphere for these settings to take effect.

.
I have a IBM PMR opened for that problem. I'll let you know if I obtain any reliable tips from IBM.

[David O'Meara]

Can I get the PMR so I can refer ours to it too?
We keep describing the problem we're experiencing but I don't think we're at the stage where they understand us yet...

[Patrick Finnegan]

The are LDAP authentication issues in 4.0.3 so I suggest upgrading to 4.0.4 and retesting. Note that DB2 7.2 and IBM LDAP 4.1.1 are pre-reqs for this fixpack.
The LTPA token expiration is an absolute value not dependent on user activity. You should set the LTPA token expiration to match the web module session timeout. If no specific web module timeout is set in the EAR(settable via AAT) then WebSphere uses the default web container session timeout. If the session timeout differs from the LTPA token timeout then results are unpredictable because either the user remains authenticated but the session times out or the session times out but the user remains authenticated.
User passwords held in LDAP are buffered twice, once in the underlying DB2 cache and once in the LDAP cache. It's possible to update user details on LDAP and not see the changes in LDAP search results because the old details are held either in the DB2 or LDAP caches which have not been flushed. If WebSphere also holds the cache then that's three caches you have to deal with.
I askted IBM to build cache flushing features into WebSphere because I hit a problem with SQL caches. Performing a global bind on DB2 say after a runstats/reorg invalidates the WebSphere prepared statement cache requiring an admin server restart.

[JeanLouis Marechaux]

Originally posted by Patrick Finnegan:
The are LDAP authentication issues in 4.0.3
Do you have some PQ or APAR numbers about that ?
If the session timeout differs from the LTPA token timeout then results are unpredictable...
Very interesting.. have to work a bit further with that...

[JeanLouis Marechaux]

Originally posted by Patrick Finnegan:
... because either the user remains authenticated but the session times out or the session times out but the user remains authenticated.

I've read and re-read this and it is still puzzling me

[JeanLouis Marechaux]

Originally posted by Patrick Finnegan:

User passwords held in LDAP are buffered twice, once in the underlying DB2 cache and once in the LDAP cache.

According to my tests, there is also a WebSphere LTPA cache. But I can't find any documentation about it.
What is the DB2 cache you are talking about ? Do you mean some information are ALWAYS stored in DB2 or ONLY when the persistent session is enabled ??

[JeanLouis Marechaux]

According to the documentation and to IBM, the security cach e timeout should rebuilds the security data once reached, WITHOUT re-challenging the web user.
But...... it challenges the user each time the timeout occurs...
Bug ???

[David O'Meara]

Bill, you messaged me but I have no way to contact you since you haven't supplied an email address
(you do know you're missing out on the javaranch newsletters? )
Anyway, send me another message with a contact email and I'll send you out PMR details. This way you can have a look and decide if they are the same problem.
Dave

[David O'Meara]

Originally posted by Bill Bailey:
Bug ???

Steaming pile.
This is definitely not the behaviour we are seeing. If anything, almost the opposite is true.
That is, they are saying the session should be allowed to timeout and force the user to re-authenticate, but if the LTPA token times out it will be re-created.
What we get is the session being recreated (as a new session) each time it times out without the user knowing. When the LTPA token times it forces the user to re-authenticate.
Doesn't sound to bad except that the LTPA timeout value is absolute. You create a token and in 5 minutes the user must re-authenticate regardless of what actions they perform.
According to my tests, there is also a WebSphere LTPA cache. But I can't find any documentation about it.
That's what we're seeing too.
...because either the user remains authenticated but the session times out or the session times out but the user remains authenticated.
I believe he's talking about the effects you can create by altering the session and LTPA timeout values.
If session<LTPA, the session times out but the user remains authenticated. On their next hit they get a completely new session. This is completely unmanagable if you use the session in any way.
If session>LTPA, when the LTPA expires the user must re-authenticate, but they retain the same session. (this was our preferred solution)
If they are the same or both of them timeout, the user must authenticate but they get also get a new session, so this behaves like a new user logging in.
Dave
[ September 11, 2002: Message edited by: David O'Meara ]

[JeanLouis Marechaux]

Originally posted by David O'Meara:
Bill, you messaged me but I have no way to contact you since you haven't supplied an email address
(you do know you're missing out on the javaranch newsletters? )
Anyway, send me another message with a contact email and I'll send you out PMR details. This way you can have a look and decide if they are the same problem.
Dave

Sorry Dave, I thought private message was enough to contact me... Anyway, I just sent you my email address...... in a private message
BTW, I do receive JavaRanch newsletters

[JeanLouis Marechaux]

Dave,

We have installed E-Fix 63547 and now the security behavior is quite different.
I have some tests to perform before being able to let you know what have changed exactly.
Could you tell me which WAS release you are running, and the patches you applied.
We are in WAS 4.03 + PQ 63547 (we removed other security efixes as IBM asked us to do it)

[JeanLouis Marechaux]

Dave, Patrick, (and others...).
My understanding is that your change password feature works fine...
Well.. Could you just try this.
1- Change the password for a user.
2 - log in with the new password
3- log in with the old password.
You should notice you are able to do both while the Security Cache Timeout is not reached....Weird.. But considered as a normal behavior by IBM

[JeanLouis Marechaux]

PQ63574 solved one of our issues (changed password not taken into account).
The caching expiration stuff we observed is a normal behaviors, as I documented in this thread