Bug 802356 - Security exception routing a message to service using secured jms-jca-provider
Summary: Security exception routing a message to service using secured jms-jca-provider
Keywords:
Status: VERIFIED
Alias: None
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBoss Messaging, JBossESB
Version: 5.2.0 GA
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ER3
: 5.3.0 GA
Assignee: Julian Coleman
QA Contact: Matej Melko
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-12 10:42 UTC by Martin Weiler
Modified: 2018-11-28 21:21 UTC (History)
4 users (show)

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.
Clone Of:
: 811277 (view as bug list)
Environment:
Last Closed:
Type: Bug
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker JBPAPP-8546 0 Major Resolved null user is not authorized for DeadMessageQueue 2013-04-19 20:37:13 UTC
Red Hat Issue Tracker JBPAPP-8680 0 Major Resolved JBMESSAGING-1920: MessagingXAResource.isSameRm() should differentiate between resources coming from connections created ... 2013-04-19 20:37:13 UTC

Description Martin Weiler 2012-03-12 10:42:01 UTC
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 10:45:55 UTC
Created attachment 569353 [details]
Modified quickstart to reproduce this issue

Comment 2 JBoss JIRA Server 2012-04-01 04:21:12 UTC
Yong Hao Gao <hgao> updated the status of jira JBPAPP-8546 to Resolved

Comment 3 Martin Weiler 2012-04-10 14:08:21 UTC
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 15:29:48 UTC
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 14:03:03 UTC
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 14:19:48 UTC
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 15:21:43 UTC
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 15:13:55 UTC
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 13:19:06 UTC
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 13:21:46 UTC
GSS prioritizes this highly.  The customer waiting on it is strategic.

Comment 11 JBoss JIRA Server 2012-05-02 11:54:46 UTC
Tushar Gandotra <tgandotra> updated the status of jira JBPAPP-8680 to Resolved

Comment 12 JBoss JIRA Server 2012-05-02 11:54:46 UTC
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

Comment 13 Julian Coleman 2012-05-29 13:40:43 UTC
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 13:59:23 UTC
Verified with soa-p.5.3 ER3.

Comment 15 Suz 2012-06-24 23:26:57 UTC
    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.