[CXF-6343] EncryptedHeader not properly processed or generated

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.0.4
• Fix Version/s: 3.1, 3.0.5
• Component/s: WS-* Components
• Estimated Complexity: Unknown
• Assignee: Colm O hEigeartaigh
• Reporter: Hugo Trippaers
• Created: 09/Apr/15 15:12
• Updated: 14/Oct/16 14:24
• Resolved: 16/Apr/15 10:07

Description

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.