[JBoss JIRA] (JBESB-3898) EBWS on CXF fails to handle WS-Security header with soap:mustUnderstand="1"
by Tadayoshi Sato (JIRA)
[ https://issues.jboss.org/browse/JBESB-3898?page=com.atlassian.jira.plugin... ]
Tadayoshi Sato commented on 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}
> 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
11 years, 1 month
[JBoss JIRA] (JBESB-3898) EBWS on CXF fails to handle WS-Security header with soap:mustUnderstand="1"
by Tadayoshi Sato (JIRA)
[ https://issues.jboss.org/browse/JBESB-3898?page=com.atlassian.jira.plugin... ]
Tadayoshi Sato commented on 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..."}}.
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...">
<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}
> 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
11 years, 1 month
[JBoss JIRA] (JBESB-3587) Enabling xslt parameters support in XsltAction
by Tadayoshi Sato (JIRA)
[ https://issues.jboss.org/browse/JBESB-3587?page=com.atlassian.jira.plugin... ]
Tadayoshi Sato updated JBESB-3587:
----------------------------------
Priority: Major (was: Minor)
> Enabling xslt parameters support in XsltAction
> ----------------------------------------------
>
> Key: JBESB-3587
> URL: https://issues.jboss.org/browse/JBESB-3587
> Project: JBoss ESB
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Transformation Service
> Affects Versions: 4.9
> Environment: Linux
> Reporter: Eduardo de Vera Toquero
> Labels: configuration, parameters, xslt:param, xsltAction
> Fix For: 4.13
>
> Attachments: xslt-param-patch.txt
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Enhancement of xslt parameters in order to be able to pass values to xslt parameters on the xslt action. Ideally, using prefixes, one could chose whether to pass a value located at the configuration file (ConfigTree) or from the ESB Message. Values need to be stringed.
--
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
11 years, 1 month
[JBoss JIRA] (JBESB-3913) Update Release Notes
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3913:
-------------------------------------
Summary: Update Release Notes
Key: JBESB-3913
URL: https://issues.jboss.org/browse/JBESB-3913
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Documentation
Affects Versions: 4.12
Reporter: Tom Cunningham
Assignee: Tom Cunningham
Fix For: 4.12
--
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
11 years, 1 month