Sorry, I can't help you. The issues appear to be specific to websphere + the SAAJ/XML dependencies that are used.
Colm. On Tue, Jun 9, 2015 at 9:07 AM, Christian Thiel <[email protected]> wrote: > Hi Colm, > > thanks for your response and fixing the NPE in Santuario. > > I was finally successful to run the service without deploying the extra > dependencies on websphere with x509 authentication and signatures but > without encryption (see attached wsdl). > > After disabling encryption in the policy because of the the wrong > EncryptedKey/EncryptedData element order, one other issue prevented me > to access the service on websphere: > > The security-policy includes the <sp:IncludeTimestamp/> element. > Therefore a timestamp is included to the message and signed. The problem > is that the canonicalization for the timestamp element is done > differently on the server and the client so that the result is a > different digest. Because of the different digest the signature check on > the client side fails (also see attached full logs): > > ### websphere log: > 2015-06-09 09:34:57.117 [WebContainer : 6] DEBUG [ElementProxy] : > setElement("ec:InclusiveNamespaces", "null") > 2015-06-09 09:34:57.117 [WebContainer : 6] DEBUG [DigesterOutputStream] > : Pre-digested input: > 2015-06-09 09:34:57.117 [WebContainer : 6] DEBUG [DigesterOutputStream] > : <wsu:Timestamp > > wsu:Id="TS-43c19cda-0210-47a8-a163-56fbebd56bd7"><wsu:Created>2015-06-09T07:34:57.117Z</wsu:Created><wsu:Expires>2015-06-09T07:39:57.117Z</wsu:Expires></wsu:Timestamp> > 2015-06-09 09:34:57.117 [WebContainer : 6] DEBUG [DOMReference] : > Reference object uri = #TS-43c19cda-0210-47a8-a163-56fbebd56bd7 > > ### client log: > 2015-06-09 09:34:57.000 [main] DEBUG [ElementProxy] : > setElement("ec:InclusiveNamespaces", "null") > 2015-06-09 09:34:57.001 [main] DEBUG [DigesterOutputStream] : > Pre-digested input: > 2015-06-09 09:34:57.001 [main] DEBUG [DigesterOutputStream] : > <wsu:Timestamp > xmlns:wsu=" > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd > " > > wsu:Id="TS-43c19cda-0210-47a8-a163-56fbebd56bd7"><wsu:Created>2015-06-09T07:34:57.117Z</wsu:Created><wsu:Expires>2015-06-09T07:39:57.117Z</wsu:Expires></wsu:Timestamp> > 2015-06-09 09:34:57.001 [main] DEBUG [DOMReference] : Expected digest: > 2wvfxrZ1hW4xIbRj8QWzaK373nI= > 2015-06-09 09:34:57.001 [main] DEBUG [DOMReference] : Actual digest: > 6bI/lMEonQwhMZV6zTFcwwPN94E= > 2015-06-09 09:34:57.001 [main] DEBUG [DOMXMLSignature] : > Reference[#TS-43c19cda-0210-47a8-a163-56fbebd56bd7] is valid: false > 2015-06-09 09:34:57.001 [main] DEBUG [DOMXMLSignature] : Couldn't > validate the References > 2015-06-09 09:34:57.001 [main] DEBUG [SignatureProcessor] : XML > Signature verification has failed > > That problem only occurs for the signed timestamp element, the other > signatures are processed correctly. If I remove the > <sp:IncludeTimestamp/> policy, everything works ok. > > Do you have any ideas how to solve the two problems with the wrong > canonicalization of the timestamp element and the wrong > EncryptedKey/EncryptedData element order? They seem to be similar > because they are both caused by invalid xml. > Especially using timestamps is desired to prevent replay attacks. > > Best regards > > Christian > > > > On 06/04/2015 12:22 PM, Colm O hEigeartaigh wrote: > > Hi, > > > > I've fixed the NPE in Santuario as reported in > > "websphere_npe_with_cxf_3_1.txt". I don't know why a CXF service deployed > > in Websphere puts the EncryptedKey below the EncryptedData without the > > dependencies you have listed. WSS4J will not accept a message containing > an > > EncryptedKey below the EncryptedData. Well formed messages should have > the > > token for encryption or signature appear above the block that is > > referencing them. > > > > Colm. > > > > On Wed, Jun 3, 2015 at 2:04 PM, Christian Thiel <[email protected]> > wrote: > > > >> Hi, > >> > >> I'm trying to get CXF working with x509 authentication on Websphere > >> 8.5.5 (with IBM JDK 1.7.64). To get the general setup running I used > >> Glen Mazza's 'doubleit' demo project 'cxf-x509-profile' from his blog ( > >> http://web-gmazza.rhcloud.com/blog/entry/cxf-x509-profile ). > >> > >> After disabling Websphere's JAXWS engine and configuring Parent-Last > >> classloading for the 'doubleit' demo application I was able to deploy > >> it. But accessing the service via the client project resulted in a > >> WSSecurityException on the client side: > >> Caused by: org.apache.wss4j.common.ext.WSSecurityException: > >> Unsupported > >> key identification: EK-3e4465da-f183-47da-a7ad-162d75e5f9ea (-> see > >> attached client_log.txt). > >> > >> Everything works fine when I deploy the same service in tomcat 7 (with > >> OpenJDK) and access it with the same client. So I compared the > >> SOAP-responses from tomcat and Websphere and figured out, that the > >> element order in the responses is different. The element > >> 'xenc:EncryptedKey' is below the element 'xenc:EncryptedData' in > >> Websphere's response. I don't know if thats really the problem, but it > >> seems that the client is confused by the different structure of the SOAP > >> response. > >> (-> see attached resonse_*.xml) > >> > >> I'm not sure if the server creates an incorrect SOAP message or if the > >> message is correct but the CXF client cannot understand it. > >> > >> I tried disabling encryption and other parts of the the > >> ws-security-policy, but I always got similar errors. Only when I > >> disabled the security-policy completely, I was able to successfully > >> access the service on Websphere - but disabling security is no option. > >> > >> I also tried switching to the latest CXF version (3.0.5 / 3.1.0, the > >> doubleit demo project uses 3.0.2), but that resulted in a NPE on the > >> server side (-> see attached file websphere_npe_with_cxf_3_1.txt). I was > >> able to solve this problem with CXF 3.1 by downgrading xmlsec to 2.0.3 > >> and got the same behaviour like with CXF 3.0.2. > >> > >> Because the client seems to be confused by the XML structure created by > >> Websphere as a workaround I tried to provide additional dependencies > >> releated to XML-processing inside the war, so that the service deployed > >> on Websphere creates the same SOAP-response like on tomcat. I took me a > >> while to solve endless ClassCastExceptions on Websphere and was finally > >> able to find a working dependency set: > >> <dependency> > >> <groupId>javax.xml.ws</groupId> > >> <artifactId>jaxws-api</artifactId> > >> <version>2.2.11</version> > >> </dependency> > >> <dependency> > >> <groupId>javax.xml.bind</groupId> > >> <artifactId>jaxb-api</artifactId> > >> <version>2.2.12</version> > >> </dependency> > >> <dependency> > >> <groupId>javax.xml.soap</groupId> > >> <artifactId>javax.xml.soap-api</artifactId> > >> <version>1.3.5</version> > >> </dependency> > >> <dependency> > >> <groupId>javax.xml.crypto</groupId> > >> <artifactId>jsr105-api</artifactId> > >> <version>1.0.1</version> > >> </dependency> > >> <dependency> > >> <groupId>com.sun.xml.messaging.saaj</groupId> > >> <artifactId>saaj-impl</artifactId> > >> <version>1.3.25</version> > >> </dependency> > >> <dependency> > >> <groupId>xerces</groupId> > >> <artifactId>xercesImpl</artifactId> > >> <version>2.9.1</version> > >> </dependency> > >> <dependency> > >> <groupId>com.sun.xml.parsers</groupId> > >> <artifactId>jaxp-ri</artifactId> > >> <version>1.4.5</version> > >> </dependency> > >> > >> With these additional dependencies the service worked also on Websphere. > >> But the solution is really only a workaround. > >> > >> Any help is appreciated to solve this problem and get rid of the > >> additional dependencies. Can anybody confirm that this is an issue on > >> the server side (combination of Websphere+CXF) or on the client side? > >> Can the creation of the SOAP-response on the server be > >> influenced/configured in a way so that it creates XML the CXF client > >> accepts ? > >> > >> > >> Best regards > >> > >> Christian Thiel > >> > >> > > > > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
