cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Thiel <>
Subject Issue with CXF on Websphere with ws-security-policy
Date Wed, 03 Jun 2015 13:04:38 GMT

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 ( ).

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
(-> 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:

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

View raw message