Bug in security cache - 4.0.4.GA

[sim-smith]

Hi All,

I've found (I think) a reasonably serious problem with JaasSecurityManager in JBoss 4.0.4.GA around caching. It doesn't happen very often but it can result in a logged-out Subject on the stack.

The root of the problem appears to be JaasSecurityManager.authenticate(), where it logs on first via defaultLogin() which results in a new SubjectContext on the stack. Authenticate() makes a subsequent call to updateCache(), which replaces the old cache entry with the new Subject, which in turn causes the LoginContext associated with the old cache entry to log out. This results in ClientLoginModule.logout() to be called, which logs out the expired Subject (by removing the Principal). It then pops the stack, which unfortunately does not result in the expired and logged-out Subject to get removed, but the recently-added Subject from defaultLogin().

This particular chain of events I would guess is mostly harmless, except in a particular situation that I find myself in:

1/ The security cache for the principal must timeout out before the web request is processed - thus we at the beginning of the request we get a Subject in the cache that has a LoginContext that is associated with a "live" Subject - it is on the stack.
2/ The security cache lookup must fail in a subsequent call within the same request where credentials do not match. Thus the getCacheInfo() call in isValid() succeeds, but validateCache() then returns false, which triggers the call to authenticate(). This happens for me when the credentials get mixed up between Strings and char[]. I've made another post on this point, but essentially ClientLoginModule generates char[] credentials, while FormAuthenticator generates Strings.

The result of this unlikely combination of events is that a Subject on the stack gets logged-out so all its Principals get removed, but it remains on the stack, causing the application to fail when trying to work out who is logged in.

I would love to suggest here an obvious and simple solution, but I can't see one at this stage.

I think that this is worthy of a JIRA issue, but I thought I would discuss it on this forum first.

I apologise - I haven't checked the source code for later versions of JBoss, but I have checked JIRA, and I couldn't find anything there.

Let me know if you need any more information.

Many thanks,

Mark

[jhmjesus]

It tries to propagate the caller security context including the ClientLoginModule in your login-config.xml. See at http://wiki.jboss.org/wiki/Wiki.jsp?page=SecurityFAQ

[sim-smith]

"jhmjesus" wrote:
It tries to propagate the caller security context including the ClientLoginModule in your login-config.xml. See at http://wiki.jboss.org/wiki/Wiki.jsp?page=SecurityFAQ

Hi jmhjesus,

Thanks for your reply. I understanding what is going on here - the setup works for us most of the time, but every now and again a request fails.

In our login-config.xml (actually it's in a jboss-service.xml embedded in our JAR in an EAR) we have two LoginModules specified, the first is our own custom one, and the second is ClientLoginModule. The ClientLoginModule is attempting to keep the security stack correct by pushing upon successful login, and popping on logout. The problem in this case is that it is popping the wrong entry, because JaasSecurityManager has just put a new entry on the stack - the ordering is wrong. A probable answer is to dispose of the invalid cache entry before attempting to re-authenticate.

We have been running our app with the cache timeout set to a very large number (100 days) to avoid previous problems and the app has been working perfectly, apart from the credentials being cached for inordinate lengths of time. I've found and fixed the previous problem, but having a small timeout causes this issue for us.

[sim-smith]

I have created a JIRA issue for this: http://jira.jboss.com/jira/browse/JBAS-4385