We have written a test to reproduce the problem (an EAR file and a client-side JAR file including a JUnit-based test file), but it does need a queue (queue/TestHornetQueue) to be set up to send the messages into.
From a servlet we do a Successful JAAS login, and then call a Session bean. In the session bean we can access the SecurityContext and the associated principle. But if we create and send a message to a HornetQ queue, the associated SecurityContext seems to be reset, as is apparent from any further call to a Session bean.
1. --> JAAS Login --> creates a LoginContext (user = xyz , pwd = test)
2. --> call a session bean --> can access the JAAS principle as "xyz"
3. --> create and send message to a hornet-queue
4. --> call the same session bean again --> principle is set to anonymous... means that the associated SecurityContext is resetted by the 3rd step.
The problem happens when sending messages into a queue from a Servlet.
It seems that the callerPrincipal is cleared (set to the un-authenticated "anonymous" user defined in standardjboss.xml) when sending the message. This seems to happen in a separate thread, so sometimes it clears immediately and sometimes it takes slightly longer (hence the call to sleep() in the test case).
There is a similar bug reported against the default JMS provider (JBoss Messaging; Jira ID JBPAPP-3636), could this be related?
This problem only occurs when using SecurityClient; it seems that using LoginContext works as expected. Both work under JBoss 5 with the default JMS provider (JBossMessaging). It may be that the SecurityClient is not intended for use inside a JBoss container, but if so, should there not be an error message in this case?
Test case is on the forum thread.