Credentials should be consistently either String or char[]
----------------------------------------------------------
Key: JBAS-4384
URL:
http://jira.jboss.com/jira/browse/JBAS-4384
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-4.0.4.GA
Reporter: Mark Sim-Smith
Assigned To: Scott M Stark
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira