Bug 902156 - EBWS on CXF fails to handle WS-Security header with soap:mustUnderstand="1"
Summary: EBWS on CXF fails to handle WS-Security header with soap:mustUnderstand="1"
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBossESB
Version: 5.3.0 GA
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Tadayoshi Sato
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 915386 947862
TreeView+ depends on / blocked
 
Reported: 2013-01-21 03:42 UTC by Tadayoshi Sato
Modified: 2025-02-10 03:27 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
: 947862 (view as bug list)
Environment:
Last Closed: 2025-02-10 03:27:19 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker JBESB-3898 0 Major Closed EBWS on CXF fails to handle WS-Security header with soap:mustUnderstand="1" 2017-11-06 01:00:04 UTC
Red Hat Issue Tracker JBESB-3906 0 Major Closed Backport JBESB-3898 to JBESB_4_11_CP2 branch 2017-11-06 01:00:04 UTC

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.


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