Hi Aki, The issue stems from the fact that the policy has multiple security bindings (Symmetric + Transport). CXF 3.0.x checks for Symmetric before Transport, CXF 3.1.x checks for Transport before Symmetric. Therefore, the Body is not encrypted in CXF 3.1.x, as encryption is handled by the transport layer. After thinking about this, I am going to change it to the old behaviour, so it will be fixed for this use-case in 3.1.2.
Colm. On Mon, Jun 15, 2015 at 2:43 PM, Aki Yoshida <[email protected]> wrote: > @Colm > Do you have an idea where the difference in the behavior comes from? > thanks. > regards, aki > > 2015-06-15 15:18 GMT+02:00 Pröls, Stefan <[email protected]>: > > Hi, > > > > here is some more info. I've attached the requests created with 3.0.5 > > and 3.1.1. > > They are very different. Actually I've done this twice since I couldn't > > believe these are the same requests... > > For instance, in 3.1.1 the body doesn't seem to be encrypted. > > > > > > Best regards, > > Stefan > > > > > > Am 15.06.2015 um 14:30 schrieb Pröls, Stefan: > >> Hi, > >> > >> there is no difference at all between my 3.0.5 and 3.1.1 setup, other > >> than that I've replaced the jar files from the (binary) CXF > >> distributions. I've also tried to recompile my code against 3.1.1 but > >> that didn't make a difference either. If also tried with 3.1.0 -- same > >> problem. > >> > >> I realize that this is hard for you to analyze without code, > >> certificates and being able to debug the whole thing... Unfortunately it > >> isn't easier for myself either. I was hoping you might be able to > >> identify the problem from the logs I sent with my first message maybe. > >> Or possibly by comparing the WS-Security stuff from the WSDL to your > >> ChangeLogs. I realize the chances ain't very good... > >> > >> > >> Best regards, > >> Stefan > >> > >> > >> Am 15.06.2015 um 14:10 schrieb Aki Yoshida: > >>> Hi Stefan, > >>> So, we have two separate issues. > >>> 1. your request message gets rejected at the server with error code > >>> R-206. It seems to say that the certificate used was not the one > >>> expected by the server? In other words, the signature itself is not > >>> corrupt but it is signed by the wrong certificate? If that is the > >>> case, it looks like there is some difference in your 3.0.5 and 3.1.1 > >>> configuration? > >>> > >>> 2. the generated SOAP fault is invalid, as it violates the SOAP 1.2's > >>> fault code rule mentioned earlier. This needs to be fixed at the > >>> server. For the CXF client, I think we can handle this condition more > >>> gracefully and not throwing UndeclaredThrowableException. > >>> > >>> regards, aki > >>> > >>> > >>> > >>> 2015-06-15 13:45 GMT+02:00 Pröls, Stefan <[email protected]>: > >>>> Hi, > >>>> > >>>> hmm, actually the server should not return a SOAP fault at all for my > >>>> request, and it doesn't if I'm creating the request with CXF 3.0.5. > >>>> > >>>> I've added a LoggingInInterceptor to catch the SOAP fault, here it is: > >>>> > >>>> <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"; > >>>> xmlns:a="http://www.w3.org/2005/08/addressing";> > >>>> <s:Header> > >>>> <a:Action > >>>> s:mustUnderstand="1">http://www.w3.org/2005/08/addressing/soap/fault > </a:Action> > >>>> > <a:RelatesTo>urn:uuid:af9c75b2-3d20-4bd3-a5b1-109d0d0e1d91</a:RelatesTo> > >>>> </s:Header> > >>>> <s:Body> > >>>> <s:Fault> > >>>> <s:Code> > >>>> <s:Value > >>>> xmlns:a="http://mps.avs.abdata.aponet.de/faults";>a:Sender</s:Value> > >>>> </s:Code> > >>>> <s:Reason> > >>>> <s:Text xml:lang="">Fehler-Code: R-206
 > >>>> Das zur Signierung der Daten verwendete Zertifikat ist > >>>> ungültig.
 > >>>> 
 > >>>> Bitte wenden Sie sich unter Angabe des Fehler-Codes > 'R-206' > >>>> an ihr Systemhaus.
 > >>>> 
 > >>>> Fehler-Code: R-206 > >>>> </s:Text> > >>>> </s:Reason> > >>>> </s:Fault> > >>>> </s:Body> > >>>> </s:Envelope> > >>>> > >>>> "Das zur Signierung der Daten verwendete Zertifikat ist ungültig" > >>>> translates to "The certificate used for signing is not valid". > >>>> > >>>> However, I'm sure it is valid. Seems like something in the signature > got > >>>> broken from the 3.0 to the 3.1 series. > >>>> > >>>> > >>>> Best regards, > >>>> Stefan > >>>> > >>>> > >>>> Am 15.06.2015 um 13:25 schrieb Aki Yoshida: > >>>>> You are using soap 1.2. and soap 1.2 allows only one of the standard > >>>>> fault codes. > >>>>> http://www.w3.org/TR/soap12-part1/#faultcodes > >>>>> http://www.w3.org/TR/soap12-part1/#tabsoapfaultcodes > >>>>> > >>>>> If you were using soap 1.1, there should be no check so your custom > >>>>> code will get accepted. > >>>>> regards, aki > >>>>> > >>>>> 2015-06-15 12:53 GMT+02:00 Pröls, Stefan <[email protected] > >: > >>>>>> Hello, > >>>>>> > >>>>>> I'm using JDK 1.8.0_45 on Linux with both CXF 3.0.5 and CXF 3.1.1. > >>>>>> > >>>>>> > >>>>>> Best regards, > >>>>>> Stefan > >>>>>> > >>>>>> > >>>>>> Am 15.06.2015 um 12:46 schrieb Aki Yoshida: > >>>>>>> which jdk version are you using? > >>>>>>> I think this has probably something to do with your jdk version. > >>>>>>> > >>>>>>> > >>>>>>> 2015-06-15 10:53 GMT+02:00 Pröls, Stefan < > [email protected]>: > >>>>>>>> Hello, > >>>>>>>> > >>>>>>>> I'm having trouble upgrading my WebService-client from CXF 3.0.5 > to 3.1.1. > >>>>>>>> It works very well with 3.0.5, but throws a > >>>>>>>> > >>>>>>>> java.lang.reflect.UndeclaredThrowableException > >>>>>>>> at com.sun.proxy.$Proxy46.holeStatusReport(Unknown > Source) > >>>>>>>> at > >>>>>>>> > de.pharmatechnik.apotheke.armin.ARMINImpl.holeStatusReport(ARMINImpl.java:348) > >>>>>>>> Caused by: com.sun.xml.messaging.saaj.SOAPExceptionImpl: > >>>>>>>> {http://mps.avs.abdata.aponet.de/faults}Sender is not a standard > Code value > >>>>>>>> at > >>>>>>>> > com.sun.xml.messaging.saaj.soap.ver1_2.Fault1_2Impl.checkIfStandardFaultCode(Fault1_2Impl.java:146) > >>>>>>>> at > >>>>>>>> > com.sun.xml.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:139) > >>>>>>>> at > >>>>>>>> > com.sun.xml.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImpl.java:102) > >>>>>>>> at > >>>>>>>> > org.apache.cxf.binding.soap.saaj.SAAJUtils.setFaultCode(SAAJUtils.java:65) > >>>>>>>> at > >>>>>>>> > org.apache.cxf.jaxws.JaxWsClientProxy.createSoapFault(JaxWsClientProxy.java:229) > >>>>>>>> at > >>>>>>>> > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157) > >>>>>>>> ... 2 more > >>>>>>>> > >>>>>>>> with 3.1.1 and currently I don't really understand what's going > wrong. > >>>>>>>> > >>>>>>>> This is the WSDL to the WebService my client tries to access: > >>>>>>>> > >>>>>>>> https://rheaavs.element44.net/AvsMpsService_R1_Variante2.wsdl > >>>>>>>> > >>>>>>>> Because of all the WS-Security stuff needed by the WS > (Certificates and > >>>>>>>> Passwords) I cannot provide a working implementation for the > client. > >>>>>>>> > >>>>>>>> However, maybe someone with a deeper knowledge of CXFs internals > can > >>>>>>>> identify the cause of the problem from the logs. I've attached two > >>>>>>>> log-files for comparison. apache-3.0.5.log is a trace of a > successful > >>>>>>>> Webservice-call with version 3.0.5, while apache-3.1.1.log logs a > >>>>>>>> failing call > >>>>>>>> of the same WS-operation with 3.1.1. > >>>>>>>> > >>>>>>>> > >>>>>>>> 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 > >>>>>> -- > >>>>>> Mit freundlichen Grüßen > >>>>>> > >>>>>> Stefan Pröls > >>>>>> Entwicklung Systemintegration > >>>>>> > >>>>>> PHARMATECHNIK GmbH & Co. KG > >>>>>> Geschäftsstelle Passau, Neuburger Str. 128, 94036 Passau > >>>>>> > >>>>>> Tel.: +49 851 98865-205, Fax: +49 851 98865-199 > >>>>>> [email protected], www.pharmatechnik.de > >>>>>> > >>>>>> ________________________________ > >>>>>> > >>>>>> 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 > >>>> -- > >>>> Mit freundlichen Grüßen > >>>> > >>>> Stefan Pröls > >>>> Entwicklung Systemintegration > >>>> > >>>> PHARMATECHNIK GmbH & Co. KG > >>>> Geschäftsstelle Passau, Neuburger Str. 128, 94036 Passau > >>>> > >>>> Tel.: +49 851 98865-205, Fax: +49 851 98865-199 > >>>> [email protected], www.pharmatechnik.de > >>>> > >>>> ________________________________ > >>>> > >>>> 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 > >> > >> -- > >> Mit freundlichen Grüßen > >> > >> Stefan Pröls > >> Entwicklung Systemintegration > >> > >> PHARMATECHNIK GmbH & Co. KG > >> Geschäftsstelle Passau, Neuburger Str. 128, 94036 Passau > >> > >> Tel.: +49 851 98865-205, Fax: +49 851 98865-199 > >> [email protected], www.pharmatechnik.de > >> > >> ________________________________ > >> > >> 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 > > > > > > -- > > Mit freundlichen Grüßen > > > > Stefan Pröls > > Entwicklung Systemintegration > > > > PHARMATECHNIK GmbH & Co. KG > > Geschäftsstelle Passau, Neuburger Str. 128, 94036 Passau > > > > Tel.: +49 851 98865-205, Fax: +49 851 98865-199 > > [email protected], www.pharmatechnik.de > > > > > > ________________________________ > > > > 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
