@Colm: thanks:

 

> No I meant the opposite. SignedParts only means that a particular header must 
> be signed IF it is present. Hence the presence of the header itself is 
> optional.
Is this new in 3.0? As I remember that I got an exception in 2.X if a header 
wasn't present, and that was the reason why David created this interceptor 
constructor that I use.

> With regards to the other issue, could you create a test-case + I'll take a 
> look?

I appreciate the help, but would like to wait with this till a kind-of of 
last-resort. It's heavily integrated in client code that I am not allowed to 
share, with private key's and other stuff that are  a bit hard to simulate. I 
am also a bit behind on schedule for the client, so I give it a few more tries 
else I have to revert back to the 2.X version for the short time and will have 
a look at using version 3.0 after the client dead lines.

If you could point me in the right direction by looking at the config/errors 
below, I would appreciate that.

 

- Ed

 

 

From: Colm O hEigeartaigh [mailto:[email protected]] 
Sent: woensdag 10 september 2014 17:44
To: Ed Bras
Cc: [email protected]
Subject: Re: Cont: upgrading cxf client to 3.0.1

 

> If I understand you correctly it's not possible to use optional header fields 
> in the Signature with SecurityPolicy.
> As such I continue using the interceptor as explained by David (see link 
> below).

No I meant the opposite. SignedParts only means that a particular header must 
be signed IF it is present. Hence the presence of the header itself is optional.

With regards to the other issue, could you create a test-case + I'll take a 
look?


Colm.

 

On Wed, Sep 10, 2014 at 4:05 PM, Ed Bras <[email protected]> wrote:

Thanks @Colm
If I understand you correctly it's not possible to use optional header fields 
in the Signature with SecurityPolicy.
As such I continue using the interceptor as explained by David (see link below).

However, when I use the new WSS4JStaxOutInterceptor interceptor it doesn't 
contain all the Signature info. As such, for now I continue using the 
WSS4JOutInterceptor that I was using before. It does contain all the signed 
info.
However, I then get xml validation error, in the cxf client, when reading the 
soap response from the remote end point.
This is because the response contains still some raw mime type kind of info. 
See below for the exact output.
This error occurs when the LoggingIn interceptor tries to output the message.
I tried to solve this by changing the order of the client interceptors, but it 
has no effect.
(Btw: When I disable the LoggingIn interceptor, I get the same error, but with 
different content (the sec:cipherSuitesFilter content), but it also has the 
mime type header info)
Below I also listed the client Spring config (works in cxf 2.X). And below the 
exception.
How can I solve this? (how/when is this raw "mime type" info stripped off)

Note: When I use the WSS4JStaxOutInterceptor interceptor, I don't get this 
mime-type kind of error. So I am not sure when direction to go: Stax and solve 
the sign issues, or the none-stax and solve the mime type issues :( Maybe I am 
mixing them both, but I can't seem to find it.

- Ed


The received response containing invalid xml output:
--------------------
--uuid:36d7c0e6-ad6e-4382-99a3-8401418deee9
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: binary
Content-ID:
<root.message @ cxf.apache.org>

<?xml version="1.0" encoding="UTF-8"?>
        <soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
                xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; 
xmlns:date="http://exslt.org/dates-and-times"; 
xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/";>
                <soapenv:Header />
                <soapenv:Body>
                        ...........
                        ...........
                </soapenv:Body>
        </soapenv:Envelope>
--------------------


The cxf client config:
--------------------
         <jaxws:client id="preProductionDigipoortAanleveren" 
serviceClass="AanleverServiceV12"  address="${url.delivery}">

        <jaxws:inInterceptors>
            <ref bean="preProductionSigningInterceptorIn"/>
            <ref bean="preProductionWsaSignaturePartsInterceptor"/>
            <ref bean="logInbound"/>
        </jaxws:inInterceptors>

        <jaxws:outInterceptors>
            <ref bean="preProductionSigningInterceptorOut"/>
                <ref bean="preProductionWsaSignaturePartsInterceptor"/>
                <ref bean="preProductionLoggingOutInterceptor" />
            <ref bean="logOutbound"/>
        </jaxws:outInterceptors>

        <jaxws:properties>
                <entry key="mtom-enabled" value="true"/>
            <entry key="signatureParts" 
value="{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp
 
<http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd%7dTimestamp>
 ;
                                                
{Element}{http://schemas.xmlsoap.org/soap/envelope/}Body 
<http://schemas.xmlsoap.org/soap/envelope/%7dBody> "/>
        </jaxws:properties>
    </jaxws:client>

    <bean id="logInbound" 
class="org.apache.cxf.interceptor.LoggingInInterceptor" />
    <bean id="logOutbound" 
class="org.apache.cxf.interceptor.LoggingOutInterceptor" />

        <!-- It will dynamically set the WSA signing parts if required, 
depending if they contain any value. See the class for details -->
        <bean id="preProductionWsaSignaturePartsInterceptor" 
class="SimpleDynamicWsaSignaturePartsInterceptor"/>


    <bean id="preProductionSigningInterceptorOut" 
class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
    <!--bean id="preProductionSigningInterceptorOut" 
class="org.apache.cxf.ws.security.wss4j.WSS4JStaxOutInterceptor"-->
        <constructor-arg>
            <map>
                <entry key="action" value="Timestamp Signature"/>
                <entry key="timeToLive" value="300" /> <!-- Timestamp TTL in 
seconds, indicates how long the message is valid -->
                <entry key="user" 
value="${pre.production.delivery.keystore.private.sign.key.alias}"/>

                <entry key="passwordCallbackRef" 
value-ref="preProductionPwdCallback"/>
                <entry key="signatureKeyIdentifier" value="DirectReference" />
                <entry key="signaturePropRefId" value="cryptoProperties"/>
                <entry key="cryptoProperties" 
value-ref="preProductionCryptoProperties"/>
            </map>
        </constructor-arg>
    </bean>

    <bean id="preProductionSigningInterceptorIn" 
class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
    <!--bean id="preProductionSigningInterceptorIn" 
class="org.apache.cxf.ws.security.wss4j.WSS4JStaxInInterceptor"-->
        <constructor-arg>
            <map>
                <entry key="action" value="Timestamp Signature"/>
                <entry key="signaturePropRefId" value="cryptoProperties"/>
                <entry key="cryptoProperties" 
value-ref="preProductionCryptoProperties"/>
            </map>
        </constructor-arg>
    </bean>

        <bean id="preProductionPwdCallback" 
class="com.ited.cxf.ClientKeystorePasswordCallback">
           <property name="passwords">
             <util:map key-type="java.lang.String" 
value-type="java.lang.String">
               <entry key="${private.sign.key.alias}" value="${ 
private.sign.key.pwd}"/>
             </util:map>
           </property>
        </bean>

        <util:properties id="preProductionCryptoProperties">
                <prop 
key="org.apache.wss4j.crypto.merlin.keystore.file">${keystore.private}</prop>
                <prop 
key="org.apache.wss4j.crypto.merlin.keystore.password">${keystore.private.pwd}</prop>

                <prop 
key="org.apache.wss4j.crypto.merlin.truststore.file">${keystore.trusted}</prop>
                <prop 
key="org.apache.wss4j.crypto.merlin.truststore.password">${keystore.trusted.pwd}</prop>
        </util:properties>

--------------------


The stracktrace:
-------------------
        at 
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:259)
 ~[cxf-rt-bindings-soap-3.0.1.jar:3.0.1]
        at 
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:62)
 ~[cxf-rt-bindings-soap-3.0.1.jar:3.0.1]
        at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
 [cxf-core-3.0.1.jar:3.0.1]
        at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798) 
~[cxf-core-3.0.1.jar:3.0.1]
        at 
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1636)
 ~[cxf-rt-transports-http-3.0.1.jar:3.0.1]
        at 
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1525)
 ~[cxf-rt-transports-http-3.0.1.jar:3.0.1]
        at 
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1330)
 ~[cxf-rt-transports-http-3.0.1.jar:3.0.1]
        at 
org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56)
 ~[cxf-core-3.0.1.jar:3.0.1]
        at 
org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215) 
~[cxf-core-3.0.1.jar:3.0.1]
        at 
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) 
~[cxf-core-3.0.1.jar:3.0.1]
        at 
org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:638) 
~[cxf-rt-transports-http-3.0.1.jar:3.0.1]
        at 
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
 ~[cxf-core-3.0.1.jar:3.0.1]
        at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
 [cxf-core-3.0.1.jar:3.0.1]
        at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514) 
~[cxf-core-3.0.1.jar:3.0.1]
        at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423) 
~[cxf-core-3.0.1.jar:3.0.1]
        at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) 
~[cxf-core-3.0.1.jar:3.0.1]
        at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) 
~[cxf-core-3.0.1.jar:3.0.1]
        at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) 
~[cxf-rt-frontend-simple-3.0.1.jar:3.0.1]
        at 
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:137) 
~[cxf-rt-frontend-jaxws-3.0.1.jar:3.0.1]
        at com.sun.proxy.$Proxy72.aanleveren(Unknown Source) ~[na:na]
....
...
Caused by: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character 
'-' (code 45) in prolog; expected '<'
 at [row,col {unknown-source}]: [3,1]
        at 
com.ctc.wstx.sr.StreamScanner.throwUnexpectedChar(StreamScanner.java:647) 
~[woodstox-core-asl-4.4.0.jar:4.4.0]
        at 
com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2054) 
~[woodstox-core-asl-4.4.0.jar:4.4.0]
        at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1131) 
~[woodstox-core-asl-4.4.0.jar:4.4.0]
        at 
com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1154) 
~[woodstox-core-asl-4.4.0.jar:4.4.0]
        at 
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:158)
 ~[cxf-rt-bindings-soap-3.0.1.jar:3.0.1]
        ... 58 common frames omitted
-------------------




> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:[email protected]]
> Sent: woensdag 10 september 2014 10:41
> To: Ed Bras
> Cc: [email protected]
> Subject: Re: Cont: upgrading cxf client to 3.0.1
>
> > > However WS-SecurityPolicy "SignedParts" should meet your
> > > requirements
> > How can I indicate that a certain signed part (like the RelatesTo
> > field) is optional?
> >
> > I thought this isn't possible and this was the reason of David's
> solution:
> >
> > http://davidvaleri.wordpress.com/2010/09/15/signing-ws-addressing-
> head
> > ers-in-apache-cxf/
> >
>
>  No, SignedParts only signs an Element (or enforces that it is signed)
> if it is present in the request.
>
> Colm.
>
>
>
> > > -----Original Message-----
> > > From: Colm O hEigeartaigh [mailto:[email protected]]
> > > Sent: dinsdag 9 september 2014 19:47
> > > To: [email protected]
> > > Subject: Re: Cont: upgrading cxf client to 3.0.1
> > >
> > > OPTIONAL_SIGNATURE_PARTS only works with the older approach of
> > > specifying "actions" for security - it doesn't work with WS-
> > > SecurityPolicy. However WS-SecurityPolicy "SignedParts" should meet
> > > your requirements. With regards to your other question, I think you
> > > need to create a testcase that reproduces the problem...
> > >
> > > Colm.
> > >
> > > On Tue, Sep 9, 2014 at 4:37 PM, Ed Bras <[email protected]> wrote:
> > >
> > > > Please some advice on the following cxf client config:
> > > >
> > > > After upgrading to 3.0.1. The security isn't included as it
> should.
> > > > To solve this I currently try to use WS-SecurityPolicy auto
> config
> > > > such that it's automatically included.
> > > > Before I did this manual as I have optional filled fields that
> > > > needed to be included in the signature, I used the solution as
> explained in:
> > > >
> > > > http://davidvaleri.wordpress.com/2010/09/15/signing-ws-
> addressing-
> > > head
> > > > ers-in
> > > > -apache-cxf/
> > > > I want to use the new WSS4J 2.0 OPTIONAL_SIGNATURE_PARTS as an
> > > alternative.
> > > >
> > > > Anyway: for some reason the policy info isn't used from the wsdl,
> > > > as such not used/included in the soap message.
> > > > I think because the wsdl location isn't known, so I added the
> > > > wsdLocation to the client, but then it complaints it can't find
> > > > the service definition.
> > > > How do I solve this? See the config below.
> > > >
> > > > Note: I define the serviceClass and address manually in the
> config
> > > > below as the Service and Port name in the wsdl are the same and
> > > > CXF didn't like that (at least not with version 2.X).
> > > > In the past I dropped a question about it in SO:
> > > >
> > > > http://stackoverflow.com/questions/13591514/how-to-deal-with-
> same-
> > > serv
> > > > ice-an
> > > > d-port-name-in-cxf
> > > >
> > > >
> > > > The client config snippet:
> > > > -------------------
> > > > <jaxws:client id="preProductionClient"
> > > > serviceClass="com.bla.service.DeliveryServiceV12"
> > > >
> > > > address="https://preprod.bla.nl/wus/2.0/deliveryservice/1.2";
> > > > wsdlLocation="/wsdl/DeliverPreProd_1.2.wsdl">
> > > > ------------
> > > >
> > > >
> > > > The exception:
> > > > --------------
> > > > Caused by:
> > > org.apache.cxf.service.factory.ServiceConstructionException:
> > > > Could not find definition for service {http://
> > > >
> > >
> https://preprod.bla.nl/wus/2.0/deliveryservice/1.2/}DeliveryServiceV12 
> <https://preprod.bla.nl/wus/2.0/deliveryservice/1.2/%7dDeliveryServiceV12> .
> > > > --------------
> > > >
> > > > - Ed
> > > >
> > > >
> > >
> > >
> > > --
> > > Colm O hEigeartaigh
> > >
> > > Talend Community Coder
> > > http://coders.talend.com
> >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com




-- 
Colm O hEigeartaigh

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

Reply via email to