You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Hugo Trippaers (JIRA)" <ji...@apache.org> on 2015/04/09 17:12:12 UTC

[jira] [Created] (CXF-6343) EncryptedHeader not properly processed or generated

Hugo Trippaers created CXF-6343:
-----------------------------------

             Summary: EncryptedHeader not properly processed or generated
                 Key: CXF-6343
                 URL: https://issues.apache.org/jira/browse/CXF-6343
             Project: CXF
          Issue Type: Bug
          Components: WS-* Components
    Affects Versions: 3.0.4
            Reporter: Hugo Trippaers


We spend quite some time getting interoperability with .NET 4.5 to work. In the end we managed to track down the problem to EncryptedHeader. .NET wraps EncryptedData for headers in an EncryptedHeader. This can be properly understood and parsed by WSS4J, however CXF will return an error first telling the client that it doesn't understand the EncryptedHeader element.

This can be fixed by adding the following QName("http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd", "EncryptedHeader") to the understood headers in the AbstractTokenInterceptor

The return path has a problem as well, the EncryptedHeaders are not generated by WSS4J while they should be (if i understand the spec correctly). This seems to be due to a bug in AbstractBindingBuilder where the method getEncryptedParts the following snippet should have Header instead of Element for headers

        List<WSEncryptionPart> signedParts = new ArrayList<WSEncryptionPart>();
        if (parts != null) {
            isBody = parts.isBody();
            for (Header head : parts.getHeaders()) {
                WSEncryptionPart wep = new WSEncryptionPart(head.getName(),
                                                            head.getNamespace(),
                                                            "Element");
                signedParts.add(wep);
            }
            
            Attachments attachments = parts.getAttachments();
            if (attachments != null) {
                WSEncryptionPart wep = new WSEncryptionPart("cid:Attachments", "Element");
                signedParts.add(wep);
            }
        }


I'm more than happy to provide a patch for this, but i'm looking for a second opinion on this analysis. 



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