[ 
https://issues.apache.org/jira/browse/CXF-7748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510766#comment-16510766
 ] 

Joerg Kessler commented on CXF-7748:
------------------------------------

When creating the test I noticed why it works for you but does not work for me. 
We have a requirement to set the key/certificate aliases dynamically. We are 
using the Camel CXF binding to set those values dynamically in the 
corresponding context. For the response we use 
populateCxfResponseFromExchange(). The point is that those methods of the 
binding that deal with the response are not called if the exchange pattern is 
OneWay and I think this is correct. For Oneway pattern there is no response 
expected. When I set the alias statically at the CXF endpoint it works.

Only MAPAggregatorImpl tries to process a reply for such a OneWay scenario. I 
did not look into the details of rebaseResponse() but to me it seems to be luck 
that this is working up now. But maybe I missed a use case here?

> WS-Addressing for One Way + Signature fails
> -------------------------------------------
>
>                 Key: CXF-7748
>                 URL: https://issues.apache.org/jira/browse/CXF-7748
>             Project: CXF
>          Issue Type: Bug
>          Components: WS-* Components
>    Affects Versions: 3.1.14
>            Reporter: Joerg Kessler
>            Priority: Major
>
> I am using CXF together in Apache Camel. I want to enable WS-Adressing for 
> the provider including signing these headers by WS-Security if requested . 
> This should especially work for One Way requests. When I set up this scenario 
> (Camel-CXF to Camel-CXF including Signature) I get the error
> org.apache.cxf.interceptor.Fault: No configured signature username detected
> The call stack is
> 2018 06 01 
> 06:57:37#+00#WARN#org.apache.cxf.phase.PhaseInterceptorChain##P1369096596#http-bio-8041-exec-5#na#wda71513f#jkt01ifl#web#w7e2e2211#na#na#na#na#Interceptor
>  for 
> \{http://xi.com/xiveri/source_runtime}JKCXF_TEST_IN\#\{http://xi.com/xiveri/source_runtime}JKCXF_TEST_IN
>  has thrown exception, unwinding noworg.apache.cxf.interceptor.Fault: No 
> configured signature username detected at 
> org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:232)
>  at 
> org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.handleBinding(AsymmetricBindingHandler.java:114)
>  at 
> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessageInternal(PolicyBasedWSS4JOutInterceptor.java:190)
>  at 
> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:109)
>  at 
> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:96)
>  at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>  at 
> org.apache.cxf.ws.addressing.impl.InternalContextUtils.rebaseResponse(InternalContextUtils.java:280)
>  at 
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:469)
>  at 
> org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.handleMessage(MAPAggregatorImpl.java:142)
>  at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>  at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>  at 
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
>  at 
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
>  at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
>  at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
>  at 
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:189)
>  at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:303)
>  at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:222)
>  at javax.servlet.http.HttpServlet.service(HttpServlet.java:755) at 
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:278)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>  at 
> com.sap.esb.security.cloud.authentication.CloudAuthenticationFilter.doFilter(CloudAuthenticationFilter.java:92)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>  at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>  at 
> com.sap.core.communication.server.CertValidatorFilter.doFilter(CertValidatorFilter.java:331)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>  at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
>  at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110)
>  at 
> org.eclipse.virgo.web.enterprise.security.valve.OpenEjbSecurityInitializationValve.invoke(OpenEjbSecurityInitializationValve.java:44)
>  at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:498)
>  at 
> com.sap.core.jpaas.security.auth.service.lib.AbstractAuthenticator.invoke(AbstractAuthenticator.java:170)
>  at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169) 
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962) 
> at 
> com.sap.core.tenant.valve.TenantValidationValve.invokeNextValve(TenantValidationValve.java:182)
>  at 
> com.sap.core.tenant.valve.TenantValidationValve.invoke(TenantValidationValve.java:97)
>  at 
> com.sap.js.statistics.tomcat.valve.RequestTracingValve.callNextValve(RequestTracingValve.java:82)
>  at 
> com.sap.js.statistics.tomcat.valve.RequestTracingValve.invoke(RequestTracingValve.java:49)
>  at 
> com.sap.core.js.monitoring.tomcat.valve.RequestTracingValve.invoke(RequestTracingValve.java:27)
>  at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) 
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
>  at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445) 
> at 
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1115)
>  at 
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
>  at 
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:622)
>  at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>  at java.lang.Thread.run(Thread.java:807) Caused by: 
> org.apache.cxf.ws.policy.PolicyException: No configured signature username 
> detected at 
> org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractCommonBindingHandler.unassertPolicy(AbstractCommonBindingHandler.java:92)
>  at 
> org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.getSignatureBuilder(AbstractBindingBuilder.java:1831)
>  at 
> org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignature(AsymmetricBindingHandler.java:711)
>  at 
> org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:188)
>  ... 52 common frames omitted
>  
> As you can see from the call stack the error occurs in MAPAggregatorImpl in a 
> code line
> InternalContextUtils.rebaseResponse(maps.getReplyTo(),
>  maps,
>  message);
> OneWay messages do not have a response. Therefore I think this code should 
> never be called in this case. The code seems to be meant for decoupled 
> endpoints which is not the case in my scenario. I have replaced the lines 
> 467-473
> i if (isOneway
>  || !ContextUtils.isGenericAddress(maps.getReplyTo())) {
>  InternalContextUtils.rebaseResponse(maps.getReplyTo(),
>  maps,
>  message);
>  } 
>  if (!isOneway) {
> by the lines 
> if (isOneway
>  && !ContextUtils.isGenericAddress(maps.getReplyTo())) {
>  InternalContextUtils.rebaseResponse(maps.getReplyTo(),
>  maps,
>  message);
>  } 
>  if (!isOneway) {
>  if(!ContextUtils.isGenericAddress(maps.getReplyTo())){
>  InternalContextUtils.rebaseResponse(maps.getReplyTo(),
>  maps,
>  message); 
>  }
> This ensures that the rebaseResponse method is only called for OneWay 
> messages if decoupled endpoints are used. After that change the test method 
> testResponderInboundNoMessageIdOneWay() fails because it is executed for non 
> decoupled scenario where there should be no inbound response message. So this 
> test should be executed for the decoupled use case:
>  @Test()
>  public void testResponderInboundNoMessageIdOneWay() throws Exception {
>  SetupMessageArgs args = new SetupMessageArgs();
>  args.requestor = false;
>  args.outbound = false;
>  args.oneway = true;
>  args.usingAddressing = false;
>  args.mapsInContext = false;
>  args.decoupled = true;
>  args.zeroLengthAction = true;
>  args.fault = false;
>  args.noMessageId = true;
>  
>  Message message = setUpMessage(args);
>  aggregator.setAllowDuplicates(false);
>  aggregator.mediate(message, true);
>  control.verify();
>  verifyMessage(message, false, false, false /*check*/);
>  } 
> Since the code is unchanged in CXF 3.2.4 I expect this problem to be present 
> also there.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to