You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Pröls, Stefan <s....@pharmatechnik.de> on 2015/04/01 11:35:08 UTC

Invalid Policy exception for EndorsingSupportingTokens with more than one token assertions

Hello,

I'm having trouble developing an Apache CXF client for the following WSDL:

https://rheaavs.element44.net/AvsMpsService_R1_Variante2.wsdl

When invoking a WS call, the following Exception is thrown:

Caused by: java.lang.IllegalArgumentException: Invalid Policy
         at
org.apache.wss4j.policy.model.AbstractTokenWrapper.parseNestedPolicy(AbstractTokenWrapper.java:71)
         at
org.apache.wss4j.policy.model.AbstractTokenWrapper.<init>(AbstractTokenWrapper.java:42)
         at
org.apache.wss4j.policy.model.SupportingTokens.<init>(SupportingTokens.java:44)
         at
org.apache.wss4j.policy.builders.SupportingTokensBuilder.build(SupportingTokensBuilder.java:44)
         at
org.apache.wss4j.policy.builders.SupportingTokensBuilder.build(SupportingTokensBuilder.java:35)
         at
org.apache.neethi.AssertionBuilderFactoryImpl.invokeBuilder(AssertionBuilderFactoryImpl.java:138)
         at
org.apache.neethi.AssertionBuilderFactoryImpl.build(AssertionBuilderFactoryImpl.java:117)
         at
org.apache.neethi.PolicyBuilder.processOperationElement(PolicyBuilder.java:224)
         at
org.apache.neethi.PolicyBuilder.getAllOperator(PolicyBuilder.java:184)
         at
org.apache.neethi.PolicyBuilder.processOperationElement(PolicyBuilder.java:217)
         at
org.apache.neethi.PolicyBuilder.getExactlyOneOperator(PolicyBuilder.java:180)
         at
org.apache.neethi.PolicyBuilder.processOperationElement(PolicyBuilder.java:215)
         at
org.apache.neethi.PolicyBuilder.getPolicyOperator(PolicyBuilder.java:174)
         at
org.apache.neethi.PolicyBuilder.getPolicy(PolicyBuilder.java:124)
         at
org.apache.cxf.ws.policy.attachment.reference.LocalServiceModelReferenceResolver.resolveReference(LocalServiceModelReferenceResolver.java:53)
         at
org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.resolveLocal(Wsdl11AttachmentPolicyProvider.java:291)
         at
org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.resolveReference(Wsdl11AttachmentPolicyProvider.java:271)
         at
org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.getElementPolicy(Wsdl11AttachmentPolicyProvider.java:219)
         at
org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.getElementPolicy(Wsdl11AttachmentPolicyProvider.java:167)
         at
org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.getElementPolicy(Wsdl11AttachmentPolicyProvider.java:160)
         at
org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.getEffectivePolicy(Wsdl11AttachmentPolicyProvider.java:97)
         at
org.apache.cxf.ws.policy.PolicyEngineImpl.getAggregatedEndpointPolicy(PolicyEngineImpl.java:451)
         at
org.apache.cxf.ws.policy.EndpointPolicyImpl.initializePolicy(EndpointPolicyImpl.java:152)
         at
org.apache.cxf.ws.policy.EndpointPolicyImpl.initialize(EndpointPolicyImpl.java:140)
         at
org.apache.cxf.ws.policy.PolicyEngineImpl.createEndpointPolicyInfo(PolicyEngineImpl.java:584)
         at
org.apache.cxf.ws.policy.PolicyEngineImpl.getEndpointPolicy(PolicyEngineImpl.java:313)
         at
org.apache.cxf.ws.policy.PolicyEngineImpl.getClientEndpointPolicy(PolicyEngineImpl.java:294)
         at
org.apache.cxf.ws.policy.PolicyDataEngineImpl.getClientEndpointPolicy(PolicyDataEngineImpl.java:61)
         at
org.apache.cxf.transport.http.HTTPConduit.updateClientPolicy(HTTPConduit.java:317)
         at
org.apache.cxf.transport.http.HTTPConduit.updateClientPolicy(HTTPConduit.java:337)
         at
org.apache.cxf.transport.http.HTTPConduit.getClient(HTTPConduit.java:860)
         at
org.apache.cxf.transport.http.HTTPConduit.configureConduitFromEndpointInfo(HTTPConduit.java:359)
         at
org.apache.cxf.transport.http.HTTPConduit.finalizeConfig(HTTPConduit.java:439)
         at
org.apache.cxf.transport.http.HTTPTransportFactory.getConduit(HTTPTransportFactory.java:242)
         at
org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:222)
         at
org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:229)
         at
org.apache.cxf.endpoint.AbstractConduitSelector.createConduit(AbstractConduitSelector.java:145)
         at
org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(AbstractConduitSelector.java:107)
         at
org.apache.cxf.endpoint.UpfrontConduitSelector.prepare(UpfrontConduitSelector.java:63)
         at
org.apache.cxf.endpoint.ClientImpl.prepareConduitSelector(ClientImpl.java:853)
         at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:511)
         at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425)
         at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
         at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
         at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
         at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138)
         ... 3 more

I've tracked this down to the sp:EndorsingSupportingTokens/wsp:Policy
which has 2 token assertions as childs: a sp:X509Token and a
sp:IssuedToken. Apparently CXF doesn't like this.

If I either remove one of these childs or put a wsp:ExactlyOne around
them, the exception will not be thrown and the SOAP-Request will be sent
but the remote server will not accept the message and return an
InvalidSecurity SOAP-Fault.

If I put a wsp:All around them instead, the "Invalid Policy" exception
will be thrown again.

I don't understand why Apache CXF throws the exception for the original
WSDL. So far, I couldn't find anything in the specs making the 2 token
assertions illegal. The specs defines theEndorsingSupportingTokens like
this:

-------------------------------------------------
<sp:EndorsingSupportingTokens xmlns:sp="..." ... >
   <wsp:Policy xmlns:wsp="...">
     [Token Assertion]+
     <sp:AlgorithmSuite ... > ... </sp:AlgorithmSuite> ?
     (
       <sp:SignedParts ... > ... </sp:SignedParts> |
       <sp:SignedElements ... > ... </sp:SignedElements> |
       <sp:EncryptedParts ... > ... </sp:EncryptedParts> |
       <sp:EncryptedElements ... > ... </sp:EncryptedElements> |
       <sp:ContentEncryptedElements ... > ... </sp:ContentEncryptedElements>
     ) *
     ...
   </wsp:Policy>
   ...
</sp:EndorsingSupportingTokens>

...

/sp:EndorsingSupportingTokens/wsp:Policy/[Token Assertion]
   The policy MUST identify one or more token assertions.
-------------------------------------------------

So did I miss something or is this a bug in Apache CXF?


Best regards,
Stefan

________________________________

PHARMATECHNIK GmbH und Co. KG
Münchner Strasse 15
D-82319 Starnberg

Sitz der Gesellschaft: Starnberg
HRA: 64434, HRB: 66369, Amtsgericht München
Geschäftsführer: Dr. Detlef Graessner, Cornelia Graessner-Neiss, Stephan Jörgens

AW: Invalid Policy exception for EndorsingSupportingTokens with more than one token assertions

Posted by Pröls, Stefan <s....@pharmatechnik.de>.
Hi Colm,

well, I've not designed this web-service interface, so I cannot comment on the reasons it has been designed like that.

My task is to develop a client connecting to this web-service, and unless they are really trying to do something not allowed by the specs, I've no evidence to argue this can't be done. So the point is, what this SecurityPolicy specifies is legal and supported by the specification. So if you are claiming to implement the specification, not supporting this scenario is a bug, IMHO (which I've filed in the issue tracker meanwhile).

Furthermore, while the design of the policy may be somewhat paranoid in requiring the whole stuff to be signed by both the STS token and the X509 certificate, this is not completely nonsense. It's paranoid, I agree, but it is not contradictory or unsecure.


Best regards,
Stefan


________________________________________
Von: Colm O hEigeartaigh <co...@apache.org>
Gesendet: Freitag, 3. April 2015 15:32
An: users@cxf.apache.org
Betreff: Re: Invalid Policy exception for EndorsingSupportingTokens with more than one token assertions

It's not a bug - we just don't support this scenario. The policy specifies
that both tokens must be endorsing - I have never seen this scenario before
- why would you need to endorse both an Issued Token and an X.509 Token? If
the service trusts the X.509 certificate then there should be no need for
the IssuedToken etc.

Colm.

On Wed, Apr 1, 2015 at 10:35 AM, Pröls, Stefan <s....@pharmatechnik.de>
wrote:

> Hello,
>
> I'm having trouble developing an Apache CXF client for the following WSDL:
>
> https://rheaavs.element44.net/AvsMpsService_R1_Variante2.wsdl
>
> When invoking a WS call, the following Exception is thrown:
>
> Caused by: java.lang.IllegalArgumentException: Invalid Policy
>          at
>
> org.apache.wss4j.policy.model.AbstractTokenWrapper.parseNestedPolicy(AbstractTokenWrapper.java:71)
>          at
>
> org.apache.wss4j.policy.model.AbstractTokenWrapper.<init>(AbstractTokenWrapper.java:42)
>          at
>
> org.apache.wss4j.policy.model.SupportingTokens.<init>(SupportingTokens.java:44)
>          at
>
> org.apache.wss4j.policy.builders.SupportingTokensBuilder.build(SupportingTokensBuilder.java:44)
>          at
>
> org.apache.wss4j.policy.builders.SupportingTokensBuilder.build(SupportingTokensBuilder.java:35)
>          at
>
> org.apache.neethi.AssertionBuilderFactoryImpl.invokeBuilder(AssertionBuilderFactoryImpl.java:138)
>          at
>
> org.apache.neethi.AssertionBuilderFactoryImpl.build(AssertionBuilderFactoryImpl.java:117)
>          at
>
> org.apache.neethi.PolicyBuilder.processOperationElement(PolicyBuilder.java:224)
>          at
> org.apache.neethi.PolicyBuilder.getAllOperator(PolicyBuilder.java:184)
>          at
>
> org.apache.neethi.PolicyBuilder.processOperationElement(PolicyBuilder.java:217)
>          at
>
> org.apache.neethi.PolicyBuilder.getExactlyOneOperator(PolicyBuilder.java:180)
>          at
>
> org.apache.neethi.PolicyBuilder.processOperationElement(PolicyBuilder.java:215)
>          at
> org.apache.neethi.PolicyBuilder.getPolicyOperator(PolicyBuilder.java:174)
>          at
> org.apache.neethi.PolicyBuilder.getPolicy(PolicyBuilder.java:124)
>          at
>
> org.apache.cxf.ws.policy.attachment.reference.LocalServiceModelReferenceResolver.resolveReference(LocalServiceModelReferenceResolver.java:53)
>          at
>
> org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.resolveLocal(Wsdl11AttachmentPolicyProvider.java:291)
>          at
>
> org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.resolveReference(Wsdl11AttachmentPolicyProvider.java:271)
>          at
>
> org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.getElementPolicy(Wsdl11AttachmentPolicyProvider.java:219)
>          at
>
> org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.getElementPolicy(Wsdl11AttachmentPolicyProvider.java:167)
>          at
>
> org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.getElementPolicy(Wsdl11AttachmentPolicyProvider.java:160)
>          at
>
> org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.getEffectivePolicy(Wsdl11AttachmentPolicyProvider.java:97)
>          at
>
> org.apache.cxf.ws.policy.PolicyEngineImpl.getAggregatedEndpointPolicy(PolicyEngineImpl.java:451)
>          at
>
> org.apache.cxf.ws.policy.EndpointPolicyImpl.initializePolicy(EndpointPolicyImpl.java:152)
>          at
>
> org.apache.cxf.ws.policy.EndpointPolicyImpl.initialize(EndpointPolicyImpl.java:140)
>          at
>
> org.apache.cxf.ws.policy.PolicyEngineImpl.createEndpointPolicyInfo(PolicyEngineImpl.java:584)
>          at
>
> org.apache.cxf.ws.policy.PolicyEngineImpl.getEndpointPolicy(PolicyEngineImpl.java:313)
>          at
>
> org.apache.cxf.ws.policy.PolicyEngineImpl.getClientEndpointPolicy(PolicyEngineImpl.java:294)
>          at
>
> org.apache.cxf.ws.policy.PolicyDataEngineImpl.getClientEndpointPolicy(PolicyDataEngineImpl.java:61)
>          at
>
> org.apache.cxf.transport.http.HTTPConduit.updateClientPolicy(HTTPConduit.java:317)
>          at
>
> org.apache.cxf.transport.http.HTTPConduit.updateClientPolicy(HTTPConduit.java:337)
>          at
> org.apache.cxf.transport.http.HTTPConduit.getClient(HTTPConduit.java:860)
>          at
>
> org.apache.cxf.transport.http.HTTPConduit.configureConduitFromEndpointInfo(HTTPConduit.java:359)
>          at
>
> org.apache.cxf.transport.http.HTTPConduit.finalizeConfig(HTTPConduit.java:439)
>          at
>
> org.apache.cxf.transport.http.HTTPTransportFactory.getConduit(HTTPTransportFactory.java:242)
>          at
>
> org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:222)
>          at
>
> org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:229)
>          at
>
> org.apache.cxf.endpoint.AbstractConduitSelector.createConduit(AbstractConduitSelector.java:145)
>          at
>
> org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(AbstractConduitSelector.java:107)
>          at
>
> org.apache.cxf.endpoint.UpfrontConduitSelector.prepare(UpfrontConduitSelector.java:63)
>          at
>
> org.apache.cxf.endpoint.ClientImpl.prepareConduitSelector(ClientImpl.java:853)
>          at
> org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:511)
>          at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425)
>          at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
>          at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
>          at
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
>          at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138)
>          ... 3 more
>
> I've tracked this down to the sp:EndorsingSupportingTokens/wsp:Policy
> which has 2 token assertions as childs: a sp:X509Token and a
> sp:IssuedToken. Apparently CXF doesn't like this.
>
> If I either remove one of these childs or put a wsp:ExactlyOne around
> them, the exception will not be thrown and the SOAP-Request will be sent
> but the remote server will not accept the message and return an
> InvalidSecurity SOAP-Fault.
>
> If I put a wsp:All around them instead, the "Invalid Policy" exception
> will be thrown again.
>
> I don't understand why Apache CXF throws the exception for the original
> WSDL. So far, I couldn't find anything in the specs making the 2 token
> assertions illegal. The specs defines theEndorsingSupportingTokens like
> this:
>
> -------------------------------------------------
> <sp:EndorsingSupportingTokens xmlns:sp="..." ... >
>    <wsp:Policy xmlns:wsp="...">
>      [Token Assertion]+
>      <sp:AlgorithmSuite ... > ... </sp:AlgorithmSuite> ?
>      (
>        <sp:SignedParts ... > ... </sp:SignedParts> |
>        <sp:SignedElements ... > ... </sp:SignedElements> |
>        <sp:EncryptedParts ... > ... </sp:EncryptedParts> |
>        <sp:EncryptedElements ... > ... </sp:EncryptedElements> |
>        <sp:ContentEncryptedElements ... > ...
> </sp:ContentEncryptedElements>
>      ) *
>      ...
>    </wsp:Policy>
>    ...
> </sp:EndorsingSupportingTokens>
>
> ...
>
> /sp:EndorsingSupportingTokens/wsp:Policy/[Token Assertion]
>    The policy MUST identify one or more token assertions.
> -------------------------------------------------
>
> So did I miss something or is this a bug in Apache CXF?
>
>
> Best regards,
> Stefan
>
> ________________________________
>
> PHARMATECHNIK GmbH und Co. KG
> Münchner Strasse 15
> D-82319 Starnberg
>
> Sitz der Gesellschaft: Starnberg
> HRA: 64434, HRB: 66369, Amtsgericht München
> Geschäftsführer: Dr. Detlef Graessner, Cornelia Graessner-Neiss, Stephan
> Jörgens
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

________________________________

PHARMATECHNIK GmbH und Co. KG
Münchner Strasse 15
D-82319 Starnberg

Sitz der Gesellschaft: Starnberg
HRA: 64434, HRB: 66369, Amtsgericht München
Geschäftsführer: Dr. Detlef Graessner, Cornelia Graessner-Neiss, Stephan Jörgens

Re: Invalid Policy exception for EndorsingSupportingTokens with more than one token assertions

Posted by Colm O hEigeartaigh <co...@apache.org>.
It's not a bug - we just don't support this scenario. The policy specifies
that both tokens must be endorsing - I have never seen this scenario before
- why would you need to endorse both an Issued Token and an X.509 Token? If
the service trusts the X.509 certificate then there should be no need for
the IssuedToken etc.

Colm.

On Wed, Apr 1, 2015 at 10:35 AM, Pröls, Stefan <s....@pharmatechnik.de>
wrote:

> Hello,
>
> I'm having trouble developing an Apache CXF client for the following WSDL:
>
> https://rheaavs.element44.net/AvsMpsService_R1_Variante2.wsdl
>
> When invoking a WS call, the following Exception is thrown:
>
> Caused by: java.lang.IllegalArgumentException: Invalid Policy
>          at
>
> org.apache.wss4j.policy.model.AbstractTokenWrapper.parseNestedPolicy(AbstractTokenWrapper.java:71)
>          at
>
> org.apache.wss4j.policy.model.AbstractTokenWrapper.<init>(AbstractTokenWrapper.java:42)
>          at
>
> org.apache.wss4j.policy.model.SupportingTokens.<init>(SupportingTokens.java:44)
>          at
>
> org.apache.wss4j.policy.builders.SupportingTokensBuilder.build(SupportingTokensBuilder.java:44)
>          at
>
> org.apache.wss4j.policy.builders.SupportingTokensBuilder.build(SupportingTokensBuilder.java:35)
>          at
>
> org.apache.neethi.AssertionBuilderFactoryImpl.invokeBuilder(AssertionBuilderFactoryImpl.java:138)
>          at
>
> org.apache.neethi.AssertionBuilderFactoryImpl.build(AssertionBuilderFactoryImpl.java:117)
>          at
>
> org.apache.neethi.PolicyBuilder.processOperationElement(PolicyBuilder.java:224)
>          at
> org.apache.neethi.PolicyBuilder.getAllOperator(PolicyBuilder.java:184)
>          at
>
> org.apache.neethi.PolicyBuilder.processOperationElement(PolicyBuilder.java:217)
>          at
>
> org.apache.neethi.PolicyBuilder.getExactlyOneOperator(PolicyBuilder.java:180)
>          at
>
> org.apache.neethi.PolicyBuilder.processOperationElement(PolicyBuilder.java:215)
>          at
> org.apache.neethi.PolicyBuilder.getPolicyOperator(PolicyBuilder.java:174)
>          at
> org.apache.neethi.PolicyBuilder.getPolicy(PolicyBuilder.java:124)
>          at
>
> org.apache.cxf.ws.policy.attachment.reference.LocalServiceModelReferenceResolver.resolveReference(LocalServiceModelReferenceResolver.java:53)
>          at
>
> org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.resolveLocal(Wsdl11AttachmentPolicyProvider.java:291)
>          at
>
> org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.resolveReference(Wsdl11AttachmentPolicyProvider.java:271)
>          at
>
> org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.getElementPolicy(Wsdl11AttachmentPolicyProvider.java:219)
>          at
>
> org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.getElementPolicy(Wsdl11AttachmentPolicyProvider.java:167)
>          at
>
> org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.getElementPolicy(Wsdl11AttachmentPolicyProvider.java:160)
>          at
>
> org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider.getEffectivePolicy(Wsdl11AttachmentPolicyProvider.java:97)
>          at
>
> org.apache.cxf.ws.policy.PolicyEngineImpl.getAggregatedEndpointPolicy(PolicyEngineImpl.java:451)
>          at
>
> org.apache.cxf.ws.policy.EndpointPolicyImpl.initializePolicy(EndpointPolicyImpl.java:152)
>          at
>
> org.apache.cxf.ws.policy.EndpointPolicyImpl.initialize(EndpointPolicyImpl.java:140)
>          at
>
> org.apache.cxf.ws.policy.PolicyEngineImpl.createEndpointPolicyInfo(PolicyEngineImpl.java:584)
>          at
>
> org.apache.cxf.ws.policy.PolicyEngineImpl.getEndpointPolicy(PolicyEngineImpl.java:313)
>          at
>
> org.apache.cxf.ws.policy.PolicyEngineImpl.getClientEndpointPolicy(PolicyEngineImpl.java:294)
>          at
>
> org.apache.cxf.ws.policy.PolicyDataEngineImpl.getClientEndpointPolicy(PolicyDataEngineImpl.java:61)
>          at
>
> org.apache.cxf.transport.http.HTTPConduit.updateClientPolicy(HTTPConduit.java:317)
>          at
>
> org.apache.cxf.transport.http.HTTPConduit.updateClientPolicy(HTTPConduit.java:337)
>          at
> org.apache.cxf.transport.http.HTTPConduit.getClient(HTTPConduit.java:860)
>          at
>
> org.apache.cxf.transport.http.HTTPConduit.configureConduitFromEndpointInfo(HTTPConduit.java:359)
>          at
>
> org.apache.cxf.transport.http.HTTPConduit.finalizeConfig(HTTPConduit.java:439)
>          at
>
> org.apache.cxf.transport.http.HTTPTransportFactory.getConduit(HTTPTransportFactory.java:242)
>          at
>
> org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:222)
>          at
>
> org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:229)
>          at
>
> org.apache.cxf.endpoint.AbstractConduitSelector.createConduit(AbstractConduitSelector.java:145)
>          at
>
> org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(AbstractConduitSelector.java:107)
>          at
>
> org.apache.cxf.endpoint.UpfrontConduitSelector.prepare(UpfrontConduitSelector.java:63)
>          at
>
> org.apache.cxf.endpoint.ClientImpl.prepareConduitSelector(ClientImpl.java:853)
>          at
> org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:511)
>          at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425)
>          at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326)
>          at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279)
>          at
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
>          at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138)
>          ... 3 more
>
> I've tracked this down to the sp:EndorsingSupportingTokens/wsp:Policy
> which has 2 token assertions as childs: a sp:X509Token and a
> sp:IssuedToken. Apparently CXF doesn't like this.
>
> If I either remove one of these childs or put a wsp:ExactlyOne around
> them, the exception will not be thrown and the SOAP-Request will be sent
> but the remote server will not accept the message and return an
> InvalidSecurity SOAP-Fault.
>
> If I put a wsp:All around them instead, the "Invalid Policy" exception
> will be thrown again.
>
> I don't understand why Apache CXF throws the exception for the original
> WSDL. So far, I couldn't find anything in the specs making the 2 token
> assertions illegal. The specs defines theEndorsingSupportingTokens like
> this:
>
> -------------------------------------------------
> <sp:EndorsingSupportingTokens xmlns:sp="..." ... >
>    <wsp:Policy xmlns:wsp="...">
>      [Token Assertion]+
>      <sp:AlgorithmSuite ... > ... </sp:AlgorithmSuite> ?
>      (
>        <sp:SignedParts ... > ... </sp:SignedParts> |
>        <sp:SignedElements ... > ... </sp:SignedElements> |
>        <sp:EncryptedParts ... > ... </sp:EncryptedParts> |
>        <sp:EncryptedElements ... > ... </sp:EncryptedElements> |
>        <sp:ContentEncryptedElements ... > ...
> </sp:ContentEncryptedElements>
>      ) *
>      ...
>    </wsp:Policy>
>    ...
> </sp:EndorsingSupportingTokens>
>
> ...
>
> /sp:EndorsingSupportingTokens/wsp:Policy/[Token Assertion]
>    The policy MUST identify one or more token assertions.
> -------------------------------------------------
>
> So did I miss something or is this a bug in Apache CXF?
>
>
> Best regards,
> Stefan
>
> ________________________________
>
> PHARMATECHNIK GmbH und Co. KG
> Münchner Strasse 15
> D-82319 Starnberg
>
> Sitz der Gesellschaft: Starnberg
> HRA: 64434, HRB: 66369, Amtsgericht München
> Geschäftsführer: Dr. Detlef Graessner, Cornelia Graessner-Neiss, Stephan
> Jörgens
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com