[jira] [Commented] (CXF-5325) error when having alternative transport bindings in WSDL

["Daniel Kulp (JIRA)" <ji...@apache.org>]

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

Daniel Kulp commented on CXF-5325:
----------------------------------


This is really working "as designed" for CXF 2.x (and maybe even 3.x).   By default, the MinimalAlternativeSelector is used on the client side which finds the policy alternative with the fewest number of policies to assert (or the first of those that are equal).  Nothing about the configuration is used while determining the policy alternative to use when sending the message.   You can configure in a different AlternativeSelector that does something different if needed.   However, at this point, the AlternativeSelector interface doesn't really provide a way to pass any configuration information into the selector (although PhaseInterceptorChain.getCurrentMessage() may work, not really sure).

> error when having alternative transport bindings in WSDL
> --------------------------------------------------------
>
>                 Key: CXF-5325
>                 URL: https://issues.apache.org/jira/browse/CXF-5325
>             Project: CXF
>          Issue Type: Bug
>          Components: Configuration
>            Reporter: Joerg Kessler
>             Fix For: 2.7.6
>
>         Attachments: cxf.client.test.sync.client.cert.junit.ext.zip
>
>
> Hi,
> we have received a WSDL from a WS provider that allows Basic Authentication or Client Certificate Authentication. When I configure Client Certificate Authentication in the conduit for my CXF WS consumer. I receive the following error
> WARNUNG: Interceptor for {http://xi.com/xiveri/source_runtime}ZMTOM_CXF_IN#{http://xi.com/xiveri/source_runtime}CXF_IN has thrown exception, unwinding now
> org.apache.cxf.ws.policy.PolicyException: Assertion of type {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}HttpsToken could not be asserted: HttpBasicAuthentication is set, but not being used
> 	at org.apache.cxf.ws.security.policy.interceptors.HttpsTokenInterceptorProvider$HttpsTokenOutInterceptor.assertHttps(HttpsTokenInterceptorProvider.java:144)
> 	at org.apache.cxf.ws.security.policy.interceptors.HttpsTokenInterceptorProvider$HttpsTokenOutInterceptor.handleMessage(HttpsTokenInterceptorProvider.java:87)
> 	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
> 	at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:541)
> 	at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:467)
> If I just allow Client Certificarte it works. If in the WSDL Client Certificate is defined first it works. If I use WSRM the Create Sequence is executed without error, the message fails. 
> I did some investigations. It seems that the HTTPSToken for Client Certificate is correctly evaluated by Neethi/CXF but some how get lost during the WSDL parsing. At the end all alternative policies contain a transport binding (referencing a transport token) referencing a HTTPSToken that requires Basic Authentication. I have attached a maven project that includes a simple junit test. It uses the Camel test functionality (CamelSpringTestSupport) to send directly a message to a CXF endpoint. mvn install or executing the junit test leads automatically to the error described above.
> Best Regards,
> Jörg



--
This message was sent by Atlassian JIRA
(v6.1#6144)