I have the same problem.
after having sent a message from a SLSB the security principal switches to the one used by JBoss Messaging!!!
What version of JBM are you using?
I believe this is something to do with context class loaders being set in messaging when doing a send.
Can you please post a bug report we will investigate.
I am using the jboss-messaging-1.0.1.SP2.
I remember I tracked into JBoss authentication code before and the username/password are stored in a Thread local variable of type SecurityAssociation. I think that is the reason why this happened: The JMS client overwrites the SecurityAssociation with its own when making the connection.
Thanks for the bug report. I scheduled it for 1.0.1.SP4, let's see ...
The problem was caused by our SecurityMetadataStore that was pushing the new Principal/Credential on the thread local's authentication info stack. I just removed that. All tests pass (including the one that I wrote for the bug).
Tim, any particular reason you did the "SecurityActions.pushSubjectContext(principal, passwordChars, subject)" thing for?
Looks like something is still wrong after all:
run: [java] Queue /queue/SmokeTestQueue exists [java] javax.jms.JMSSecurityException: User: null is not authorized to write to destination SmokeTestQueue [java] at org.jboss.jms.server.container.SecurityAspect.check(SecurityAspect.java:267) [java] at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:148) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] at java.lang.reflect.Method.invoke(Method.java:324)
I stopped the SP4 release because of this.