Description of problem: If one service is called with jms security defined, using jms-jca-provider, any subsequent call to a secured jms service still seems to use the old credentials. More information in the readme.txt of the attached quickstart, which can be used to reproduce the problem. How reproducible: always Steps to Reproduce: see readme.txt in attached quickstart Actual results: Routing the message to the second secured service fails with: ERROR [ResourceManager] org.jboss.jms.exception.MessagingXAException: A security exception happend! org.jboss.jms.exception.MessagingXAException: A security exception happend! at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:716) at org.jboss.jms.tx.ResourceManager.commit(ResourceManager.java:392) at org.jboss.jms.tx.MessagingXAResource.commit(MessagingXAResource.java:255) at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:811) at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2656) at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1784) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:94) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:160) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1431) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:137) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) at org.jboss.soa.esb.listeners.jca.EndpointProxy.endTransaction(EndpointProxy.java:401) at org.jboss.soa.esb.listeners.jca.EndpointProxy.delivery(EndpointProxy.java:281) at org.jboss.soa.esb.listeners.jca.EndpointProxy.invoke(EndpointProxy.java:150) at $Proxy418.onMessage(Unknown Source) at org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:179) ... Caused by: javax.jms.JMSSecurityException: User: user1 is not authorized to write to destination quickstart_jms_secured_service2 at org.jboss.jms.server.container.SecurityAspect.check(SecurityAspect.java:311) at org.jboss.jms.server.container.SecurityAspect.handleSendTransaction(SecurityAspect.java:191) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) Expected results: Second service is called over secured jms queue. Additional info: The same sample works fine if jms-listener is used.
Created attachment 569353 [details] Modified quickstart to reproduce this issue
Yong Hao Gao <hgao> updated the status of jira JBPAPP-8546 to Resolved
Fixed in JBoss Messaging 1.4.0.SP3.CP15, 1.4.8.SP7: https://issues.jboss.org/browse/JBMESSAGING-1920
This BZ has been hijacked for inclusion in 5.3, per the flags above. A clone has been made for SOA-P 5.2, to be used in the next Roll up (05/29/2012).
SOA-P 5.3 will be based on EAP 5.1.2GA According to DOC-70773, EAP5.1.2 used Messaging 1.4.2SP5, we need SP8. Opened a JIRA to request a build of EAP 5.1.2 that we can use for SOA-P 5.3: https://issues.jboss.org/browse/JBPAPP-8680
The above comment is wrong. We need 1.4.8SP7, not 1.4.2SP8. JIRA JBPAPP-8680 updated accordintly.
EAP has supplied the patch on https://issues.jboss.org/browse/JBPAPP-8680. I'll work with EAP to schedule QE of this patch, but it will probably not be soon. They have other Messaging bugs scheduled for QE, this will need to be properly prioritized and probably won't be one of the first.
EAP needs to know when we'll need this. (It's for SOA-P 5.3, so will check with SOA-PM for timing.)
JBPAPP-8680 has cleared QE. Productization, please use the artifacts attached to JBPAPP-8680 as input to SOA-P 5.3. Thanks, Rick
GSS prioritizes this highly. The customer waiting on it is strategic.
Tushar Gandotra <tgandotra> updated the status of jira JBPAPP-8680 to Resolved
Tushar Gandotra <tgandotra> made a comment on jira JBPAPP-8680 This patch is applicable to JBoss Enterprise Application Platform (EAP) 5.1.1. It is available for download from the following location: https://access.redhat.com/jbossnetwork/restricted/softwareDetail.html?softwareId=11973
Resolved with revision 10960 of: src/main/common/resources/eap/JBPAPP-8680/jboss-messaging-client.jar src/main/common/resources/eap/JBPAPP-8680/jboss-messaging.jar Commit message: Added patch for BZ802356 / JBPAPP-8680
Verified with soa-p.5.3 ER3.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: A bug was present in previous versions when users would attempt to route a message to a service using secured jms-jca-provider. If one service is called with jms security defined and uses jms-jca-provider, any subsequent call to a secured jms service uses outdated credentials. This has now been patched. As a result, the latest credentials will be applied when this service is invoked.