Wss4jSecurityInterceptor not decrypting reply

Question

I have a web service client implemented in Spring-ws, using a Wss4jSecurityInterceptor for ws-security.

Calling the endpoint works, data is encrypted, signed and sent, but when the reply is received it is not decrypted. Instead JAXB's unmarshaller is called, resulting in an error like :

Error : org.springframework.oxm.jaxb.JaxbUnmarshallingFailureException:
JAXB unmarshalling exception: unexpected element 
(uri:"http://www.w3.org/2001/04/xmlenc#", local:"EncryptedData"). 
Expected elements are...

Expected elements then goes on to list every data type in the xdd.

This is what my Wss4jSecurityIntercepter is configured with :

<!-- username / password for signing -->
<property name="enableSignatureConfirmation" value="false" />
<property name="securementUsername" value="${securementUsername}" />
<property name="securementSignatureKeyIdentifier" value="DirectReference" />
<property name="securementPassword" value="${keystore.password}" />
<property name="securementSignatureCrypto" ref="crypto" />

<!-- username (certificate) and keystore for encryption -->
<property name="securementEncryptionUser" value="${securementEncryptionUsername}" />
<property name="securementEncryptionKeyIdentifier" value="SKIKeyIdentifier" />
<property name="securementEncryptionCrypto" ref="crypto" />

<!-- validate incoming message signature and decrypt -->
<property name="validationActions" value="Signature Encrypt Timestamp" />
<property name="validationDecryptionCrypto" ref="crypto" />
<property name="validationSignatureCrypto" ref="crypto" />

<property name="validationCallbackHandler">
    <bean
        class="org.springframework.ws.soap.security.wss4j.callback.KeyStoreCallbackHandler">
        <property name="privateKeyPassword" value="${keystore.password}" />
    </bean>
</property>

Any idea what goes wrong ?

Thanks.

EDIT: This was caused by a ClientInterceptor that returned false on handleResponse, and was located before the wss4j interceptor, causing all Interceptor processing to stop.

Answer 1

Caused by misconfiguration of the Interceptors. (see EDIT in original question)

Answer 2

Your root cause is probably related to the order in which the securement of the message was made from the other side:

The order of the actions is significant and is enforced by the interceptor. The interceptor will reject an incoming SOAP message if its security actions were performed in a different order than the one specified by validationActions.

I would recommend that you increase your log level (Add log4j if you are not already using it to see why the interceptor was not able to decrypt the message.

Last but not least, you should implement validator to prevent your process to go further if the message was not decrypted.