You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Christian Thiel <c....@tarent.de> on 2015/06/03 15:04:38 UTC
Issue with CXF on Websphere with ws-security-policy
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
Re: Issue with CXF on Websphere with ws-security-policy
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <c....@tarent.de> 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 <c....@tarent.de>
> 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
Re: Issue with CXF on Websphere with ws-security-policy
Posted by Christian Thiel <c....@tarent.de>.
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 <c....@tarent.de> 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
>>
>>
>
>
Re: Issue with CXF on Websphere with ws-security-policy
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <c....@tarent.de> 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