public void testJmsMethod()
{
// TRANSACTION BEGINS; org.jboss.security.SecurityAssociation.getSubject() returns current Subject
ApplicationUser appUser... // user object retrieved from current Subject
Context jndiContext = new InitialContext();
QueueConnectionFactory factory = (QueueConnectionFactory) jndiContext.lookup("java:/JmsXA");
QueueConnection conn = factory.createQueueConnection(appUser.getUserId(), appUser.getPassword());
Queue queue = (javax.jms.Queue) jndiContext.lookup("queue/nameOfQueue");
QueueSession session = connection.createQueueSession(true, Session.AUTO_ACKNOWLEDGE);
// #1 USER HAS BEEN RE-AUTHENTICATED (new JAAS subject)
QueueSender sender = session.createSender(queue);
MapMessage message = session.createMapMessage();
sender.send(message);
conn.close();
}
// #2 TRANSACTION COMPLETES; org.jboss.security.SecurityAssociation.getSubject() returns null

#1. User is re-authenticated – even though the username and credential are for the current user – ecause the JaasSecurity.validateCache method returns false. The method does so because the web layer stores the user credential as a String, so the cached DomainInfo.credential is a string; but the SpyXAConnection calls JaasSecurityManager.isValid using a char[] as the credential. Cache validation will never consider char[] and String to be equivalent even if the underlying character sequence is identical.

#2. Security association for the thread has been cleared. This appears to happen when the transaction completes, indicating it is done by a Synchronization listener. Normally, the security association is cleared by the SecurityAssociation valve in Tomcat.

Workarounds are possible by ensuring that any JMS message sending is the absolute last thing that occurs during a request, but this is not optimal. The re-authentication also discards information stored in the Subject that was added after the login process.

It would be helpful is JBoss would choose a standard format for user credentials so as to prevent this problem.