You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Ben Preston (JIRA)" <ji...@apache.org> on 2014/09/02 11:13:21 UTC

[jira] [Issue Comment Deleted] (CXF-5983) Security processing failed (actions mismatch) occurs due to ENCR action appearing twice

     [ https://issues.apache.org/jira/browse/CXF-5983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ben Preston updated CXF-5983:
-----------------------------
    Comment: was deleted

(was: This is the response XML that is causing the mismatch.)

> Security processing failed (actions mismatch) occurs due to ENCR action appearing twice
> ---------------------------------------------------------------------------------------
>
>                 Key: CXF-5983
>                 URL: https://issues.apache.org/jira/browse/CXF-5983
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-WS Runtime
>    Affects Versions: 2.7.11
>         Environment: Windows 7
> Windows Vista
>            Reporter: Ben Preston
>         Attachments: MismatchResponse.xml
>
>
> I am receiving a response from a server which has the following actions: Timestamp Encrypt Signature. 
> However when the response hits the inbound interceptor (WSS4JInInterceptor) it is throwing the following exception:
> Sep 01, 2014 2:07:49 PM org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor checkActions
> WARNING: Security processing failed (actions mismatch)
> Sep 01, 2014 2:07:49 PM org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor handleMessage
> WARNING:
> org.apache.ws.security.WSSecurityException: An error was discovered processing the <wsse:Security> header
>         at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.checkActions(WSS4JInInterceptor.java:354)
> The inbound configuration aspects are as follows:
>        //Inbound Policy Rules
>         inProps.put("action", "Timestamp Encrypt Signature");
>         inProps.put("passwordCallbackClass", "reply.solidsoft.emvs.common.EmvsPasswordCallback");
>         inProps.put("decryptionPropFile", EmvsProperties.val(propPrefix + "resp.propFile"));
>         inProps.put("signaturePropFile", EmvsProperties.val(propPrefix + "enc.propFile"));
>         inProps.put("encryptionKeyIdentifier", "Thumbprint");
>         inProps.put("signatureKeyIdentifier", "DirectReference");
>         inProps.put("encryptionKeyTransportAlgorithm", "http://www.w3.org/2001/04/xmlenc#rsa-1_5");
>         inProps.put("signatureAlgorithm", "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256");
>         inProps.put("signatureDigestAlgorithm", "http://www.w3.org/2001/04/xmlenc#sha256");
>         inProps.put("encryptionSymAlgorithm", "http://www.w3.org/2001/04/xmlenc#aes256-cbc");
>         client.getInInterceptors().add(new WSS4JInInterceptor(inProps));
> I have debugged the code in Netbeans and the issue stems from CXF erroneously misreading the actions on the incoming message. The WSS4JInInterceptor (or rather the classes/methods it calls) determines that the message has the following actions (see WSConstants.java):
> hex constant/tag value
> 4/ENCR
> 2/SIGN
> 4/ENCR
> 1000/BST
> 20/TS
> It can be seen that the security engine determines that ENCR occurs twice. This causes WSHandler.java - checkReceiverResultsAnyOrder() to throw the mismatch error. I have managed a temporary work around by creating my own version of this code and ignoring the first/erroneous ENCR action. This lets the code execute without error and all parts are decrypted perfectly. As such I don't believe that the response message is at fault. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)