[
https://issues.apache.org/jira/browse/CXF-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14497871#comment-14497871
]
ASF GitHub Bot commented on CXF-6343:
-------------------------------------
Github user spark404 commented on the pull request:
https://github.com/apache/cxf/pull/66#issuecomment-93700924
Thanks for merging @coheigea
I don't know the policy in CXF but in general is good to keep the original
author the author of the commit to trace contributions with regards to the
Apache License. And of course it is more inviting for new contributors when
they see their commits popup in the code base.
> 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)