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)
