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

Reply via email to