[esb-issues] [JBoss JIRA] (JBESB-3898) EBWS on CXF fails to handle WS-Security header with soap:mustUnderstand="1"

RH Bugzilla Integration (JIRA) jira-events at lists.jboss.org
Thu Apr 4 03:33:43 EDT 2013


    [ https://issues.jboss.org/browse/JBESB-3898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764849#comment-12764849 ] 

RH Bugzilla Integration commented on JBESB-3898:
------------------------------------------------

Tadayoshi Sato <tasato at redhat.com> made a comment on [bug 947862|https://bugzilla.redhat.com/show_bug.cgi?id=947862]

Hi Rick,

No, this regression is by no means caused by BZ902156. The error [1] reproduced by comment 13 of BZ915386 indicates it stems from the invoked web service not SOAPClient. And I confirmed in my environment that if all BZ915386 patches but CXF upgrade is applied  the error doesn't happen. I believe the root cause should be found in the following BZs:
- [BZ-858926] [CVE-2012-3451] jbossws-cxf, apache-cxf: SOAPAction spoofing on document literal web services
- [BZ-896338] [CVE-2012-5633] jbossws-cxf, apache-cxf: Bypass of security constraints on WS endpoints

I also doubt that this is a regression of JBoss ESB or SOA-P as no behaviours in JBoss ESB seem to change; what's changed is JBoss WS. So, should we close this BZ and chase it as a JBoss WS regression instead?

Thank you!

[1]
15:33:39,174 WARNING [PhaseInterceptorChain] Interceptor for {http://webservice_consumer1/helloworld}HelloWorldWSService#{http://webservice_consumer1/helloworld}sayHello has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: The given SOAPAction sayHello does not match an operation.
	at org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor$SoapActionInAttemptTwoInterceptor.handleMessage(SoapActionInInterceptor.java:192)
	at org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor$SoapActionInAttemptTwoInterceptor.handleMessage(SoapActionInInterceptor.java:164)
	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)
	at java.lang.Thread.run(Thread.java:722)
                
> EBWS on CXF fails to handle WS-Security header with soap:mustUnderstand="1"
> ---------------------------------------------------------------------------
>
>                 Key: JBESB-3898
>                 URL: https://issues.jboss.org/browse/JBESB-3898
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: 4.11
>         Environment: SOA-P installed with JBoss WS CXF stack
>            Reporter: Tadayoshi Sato
>            Assignee: Magesh Bojan
>             Fix For: 4.12
>
>
> 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:
> {code}
> <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>
> {code}
> And got the following SOAP Fault:
> {code}
> <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>
> {code}
> I also got the following error stacktrace:
> {code}
> 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)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the esb-issues mailing list