[
https://issues.apache.org/jira/browse/CXF-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-6343:
-------------------------------------
Fix Version/s: 3.0.5
3.1.0
> 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
> Assignee: Colm O hEigeartaigh
> Fix For: 3.1.0, 3.0.5
>
>
> 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)
