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