Bug 902156

Summary:	EBWS on CXF fails to handle WS-Security header with soap:mustUnderstand="1"
Product:	[JBoss] JBoss Enterprise SOA Platform 5	Reporter:	Tadayoshi Sato <tasato>
Component:	JBossESB	Assignee:	Tadayoshi Sato <tasato>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	5.3.0 GA	CC:	soa-p-jira
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	947862 (view as bug list)		Environment:
Last Closed:	2025-02-10 03:27:19 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	915386, 947862

Description Tadayoshi Sato 2013-01-21 03:42:33 UTC

Description of problem:
Platform BZ for https://issues.jboss.org/browse/JBESB-3898

On JBoss WS CXF, EBWS (ESB-based web service) throws SOAP Faults when handling SOAP requests with the WS-Security UsernameToken header which is declared with soap:mustUnderstand="1", even though <security moduleName="..."/> (I believe this enables WS-Security for EBWS) is set up for the EBWS in jboss-esb.xml.

Note that I confirmed JBoss WS CXF itself can handle WS-Security with soap:mustUnderstand="1" if jbossws-cxf.xml is properly set up. So, I suspect the problem would be in EBWS.

I used the following SOAP request:
--------------------------------------------------
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:say="http://www.jboss.org/sayHi" xmlns:cust="http://www.jboss.org/custom-request" xmlns:sub="http://www.jboss.org/custom-subtype" xmlns:t="http://www.jboss.org/type2">
   <soap:Header>
      <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd">
         <wsse:UsernameToken>
            <wsse:Username>kermit</wsse:Username>
            <wsse:Password>thefrog</wsse:Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soap:Header>
   <soap:Body>
      ...
   </soap:Body>
</soap:Envelope>

And got the following SOAP Fault:
--------------------------------------------------
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Header>
      <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"/>
   </soap:Header>
   <soap:Body>
      <soap:Fault>
         <faultcode>soap:MustUnderstand</faultcode>
         <faultstring>MustUnderstand headers: [{http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd}Security] are not understood.</faultstring>
      </soap:Fault>
   </soap:Body>
</soap:Envelope>

I also got the following error stacktrace:
--------------------------------------------------
17:04:09,572 WARNING [PhaseInterceptorChain] Interceptor for {http://soa.jboss.org/ESBServiceSample}HelloWorldPubServiceService#{http://soa.jboss.org/ESBServiceSample}HelloWorldPubServiceOp has thrown exception, unwinding now
org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd}Security] are not understood.
        at org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:225)
        at org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:199)
        at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
        at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:111)
        at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:99)
        at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:431)
        at org.jboss.wsf.stack.cxf.ServletControllerExt.invoke(ServletControllerExt.java:173)
        at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:61)
        at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:185)
        at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
        at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
        at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.internalProcess(ActiveRequestResponseCacheValve.java:74)
        at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:47)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:599)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)


How reproducible:
Easily by using a quickstart.

Steps to Reproduce:
1. Pick up the "publish_as_webservice" quickstart.
2. Add soap:mustUnderstand="1" to the wsse:Security SOAP Header in soap-userpass-message.xml.
3. Send this message as a request to the "ESBServiceSample:HelloWorldPubService" service using soapUI.
  
Actual results:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Header>
      <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"/>
   </soap:Header>
   <soap:Body>
      <soap:Fault>
         <faultcode>soap:MustUnderstand</faultcode>
         <faultstring>MustUnderstand headers: [{http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd}Security] are not understood.</faultstring>
      </soap:Fault>
   </soap:Body>
</soap:Envelope>

Expected results:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Header/>
   <SOAP-ENV:Body>
      <say:sayHiResponse xmlns:say="http://www.jboss.org/sayHi">
         <say:arg0>Response from ESB Service</say:arg0>
      </say:sayHiResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Comment 1 JBoss JIRA Server 2013-02-13 14:59:18 UTC

Magesh Bojan <mageshbk> updated the status of jira JBESB-3898 to Resolved

Comment 2 JBoss JIRA Server 2013-02-13 14:59:18 UTC

Magesh Bojan <mageshbk> made a comment on jira JBESB-3898

Trunk At revision: 38280

Comment 3 Rick Wagner 2013-02-25 16:12:06 UTC

Tadayoshi, please backport Magesh's fix into the 4.11 codebase.  

Thank you,

Rick

Comment 4 Tadayoshi Sato 2013-02-27 16:20:12 UTC

Committed at rev. 38289 to JBESB_4_11_CP2 branch.

Comment 5 JBoss JIRA Server 2013-03-15 17:18:28 UTC

Tom Cunningham <tcunning> updated the status of jira JBESB-3898 to Closed

Comment 6 JBoss JIRA Server 2013-03-15 20:12:37 UTC

Tom Cunningham <tcunning> updated the status of jira JBESB-3906 to Closed

Comment 7 JBoss JIRA Server 2013-03-27 01:40:18 UTC

Tadayoshi Sato <tadayosi> made a comment on jira JBESB-3898

For the record, the namespace {{xmlns:wsse="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"}} turned out to be incorrect for WS-Security 1.0 and 1.1. The correct namespace is {{xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"}}.

So the correct SOAP request have to be:

{code:xml}
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:say="http://www.jboss.org/sayHi" xmlns:cust="http://www.jboss.org/custom-request" xmlns:sub="http://www.jboss.org/custom-subtype" xmlns:t="http://www.jboss.org/type2">
   <soap:Header>
      <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:UsernameToken>
            <wsse:Username>kermit</wsse:Username>
            <wsse:Password>thefrog</wsse:Password>
         </wsse:UsernameToken>
      </wsse:Security>
   </soap:Header>
   <soap:Body>
      ...
   </soap:Body>
</soap:Envelope>
{code}

Comment 8 JBoss JIRA Server 2013-03-28 07:56:53 UTC

Tadayoshi Sato <tadayosi> made a comment on jira JBESB-3898

Another note for the record. In order to enable WS-Security with this fix, you need the global {{<war-security>}} configuration at the beginning of {{jboss-esb.xml}} as follows:

{code:xml}
<jbossesb ...>

    <globals>
        <war-security domain="JBossWS" />
    </globals>
{code}

Comment 10 Red Hat Bugzilla 2025-02-10 03:27:19 UTC

This product has been discontinued or is no longer tracked in Red Hat Bugzilla.