Maybe you can tell me where (which class/component) is responsible of striping off this content header type info in the soap response (see my xml response below that contains this info). As such that I can search why this doesn't occur?
For some reason it's not removed Basically what I did was following the upgrade steps: changes the namespace/packages (not using the new stax WSS4J interceptor). I think I am missing something (in the stacktrace I see that a Stax readers is processing the xml, but I am not sure that was already there in the 2.7.x verion) - Ed > -----Original Message----- > From: Ed Bras [mailto:z...@debrasjes.com] > Sent: woensdag 10 september 2014 18:23 > To: cohei...@apache.org > Cc: users@cxf.apache.org > Subject: RE: Cont: upgrading cxf client to 3.0.1 > > @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:cohei...@apache.org] > Sent: woensdag 10 september 2014 17:44 > To: Ed Bras > Cc: users@cxf.apache.org > 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 <z...@debrasjes.com> 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.priva > te.pwd}</prop> > > <prop > key="org.apache.wss4j.crypto.merlin.truststore.file">${keystore.trusted > }</prop> > <prop > key="org.apache.wss4j.crypto.merlin.truststore.password">${keystore.tru > sted.pwd}</prop> > </util:properties> > > -------------------- > > > The stracktrace: > ------------------- > at > org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMe > ssage(ReadHeadersInterceptor.java:259) ~[cxf-rt-bindings-soap- > 3.0.1.jar:3.0.1] > at > org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMe > ssage(ReadHeadersInterceptor.java:62) ~[cxf-rt-bindings-soap- > 3.0.1.jar:3.0.1] > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor > Chain.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.handleRes > ponseInternal(HTTPConduit.java:1636) ~[cxf-rt-transports-http- > 3.0.1.jar:3.0.1] > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRes > ponse(HTTPConduit.java:1525) ~[cxf-rt-transports-http-3.0.1.jar:3.0.1] > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTT > PConduit.java:1330) ~[cxf-rt-transports-http-3.0.1.jar:3.0.1] > at > org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutp > utStream.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$MessageSenderEnding > Interceptor.handleMessage(MessageSenderInterceptor.java:62) ~[cxf-core- > 3.0.1.jar:3.0.1] > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor > Chain.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:64 > 7) ~[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.handleMe > ssage(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:cohei...@apache.org] > > Sent: woensdag 10 september 2014 10:41 > > To: Ed Bras > > Cc: users@cxf.apache.org > > 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:cohei...@apache.org] > > > > Sent: dinsdag 9 september 2014 19:47 > > > > To: users@cxf.apache.org > > > > 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 <z...@debrasjes.com> > 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/%7dDeliveryServiceV > 12> . > > > > > -------------- > > > > > > > > > > - 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
