Bug 802356 - Security exception routing a message to service using secured jms-jca-provider
Security exception routing a message to service using secured jms-jca-provider
Status: VERIFIED
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBoss Messaging, JBossESB (Show other bugs)
5.2.0 GA
Unspecified Unspecified
urgent Severity urgent
: ER3
: 5.3.0 GA
Assigned To: Julian Coleman
Matej Melko
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-12 06:42 EDT by Martin Weiler
Modified: 2015-11-02 03:06 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
: 811277 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Modified quickstart to reproduce this issue (15.33 KB, application/x-gzip)
2012-03-12 06:45 EDT, Martin Weiler
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBPAPP-8546 Major Resolved null user is not authorized for DeadMessageQueue 2013-04-19 16:37:13 EDT
JBoss Issue Tracker JBPAPP-8680 Major Resolved JBMESSAGING-1920: MessagingXAResource.isSameRm() should differentiate between resources coming from connections created ... 2013-04-19 16:37:13 EDT

  None (edit)
Description Martin Weiler 2012-03-12 06:42:01 EDT
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.
Comment 1 Martin Weiler 2012-03-12 06:45:55 EDT
Created attachment 569353 [details]
Modified quickstart to reproduce this issue
Comment 2 JBoss JIRA Server 2012-04-01 00:21:12 EDT
Yong Hao Gao <hgao@redhat.com> updated the status of jira JBPAPP-8546 to Resolved
Comment 3 Martin Weiler 2012-04-10 10:08:21 EDT
Fixed in JBoss Messaging 1.4.0.SP3.CP15, 1.4.8.SP7:
https://issues.jboss.org/browse/JBMESSAGING-1920
Comment 4 Rick Wagner 2012-04-10 11:29:48 EDT
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).
Comment 5 Rick Wagner 2012-04-11 10:03:03 EDT
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
Comment 6 Rick Wagner 2012-04-11 10:19:48 EDT
The above comment is wrong.  We need 1.4.8SP7, not 1.4.2SP8.  JIRA JBPAPP-8680 updated accordintly.
Comment 7 Rick Wagner 2012-04-12 11:21:43 EDT
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.
Comment 8 Rick Wagner 2012-04-13 11:13:55 EDT
EAP needs to know when we'll need this.  (It's for SOA-P 5.3, so will check with SOA-PM for timing.)
Comment 9 Rick Wagner 2012-04-26 09:19:06 EDT
JBPAPP-8680 has cleared QE.  

Productization, please use the artifacts attached to JBPAPP-8680 as input to SOA-P 5.3.

Thanks,

Rick
Comment 10 Rick Wagner 2012-04-26 09:21:46 EDT
GSS prioritizes this highly.  The customer waiting on it is strategic.
Comment 11 JBoss JIRA Server 2012-05-02 07:54:46 EDT
Tushar Gandotra <tgandotra@redhat.com> updated the status of jira JBPAPP-8680 to Resolved
Comment 12 JBoss JIRA Server 2012-05-02 07:54:46 EDT
Tushar Gandotra <tgandotra@redhat.com> 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
Comment 13 Julian Coleman 2012-05-29 09:40:43 EDT
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
Comment 14 Jiri Sedlacek 2012-06-12 09:59:23 EDT
Verified with soa-p.5.3 ER3.
Comment 15 Suz 2012-06-24 19:26:57 EDT
    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.

Note You need to log in before you can comment on or make changes to this bug.