I think that I have found an issue with the representations of Credentials in JBoss - sometimes they are java.lang.String, and other times char[]. (This is for JBoss 4.0.4.GA but I think this applies to other versions - I've just checked the head of the security trunk in SVN). In particular, org.jboss.web.tomcat.security.SecurityAssociationValve uses Strings (actually the root class is probably FormAuthenticator?), and org.jboss.security.ClientLoginModule uses char[] (because it comes in from the UsernamePasswordHandler).

This causes a problem with the caching, because the credentials are stored initially as a String (because of the SecurityAssociationValve), and when accessing an EJB the ClientLoginModule pushes onto the SecurityContext stack with char[] credentials, and so the cache lookup fails (org.jboss.security.plugins.JaasSecurityManager.validateCache()).

As it turns out this is of little conseqence in itself because it just results in another authentication, and hits the login modules again. It happens to trigger another problem though, but I'll save that for another issue.

I would suggest though that this is a minor bug - JBoss should be consistent here to avoid the additional hit on the credential cache. Probably the best approach would be to modify either the ClientLoginModule to use a String, or SecurityAssociationValve/FormAuthenticator to use a char[].

I have managed to find a workaround - to use the password-sharing option of the ClientLoginModule to pass the credentials into the ClientLoginModule as a String instead of letting the ClientLoginModule resolve the password itself via a PasswordHandler where the credentials appear as a char[] instead.

This doesn't obviate the need to change JBoss to make credential handling consistent, but at least gets around my immediate problem.