cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CXF-6343) EncryptedHeader not properly processed or generated
Date Thu, 16 Apr 2015 10:24:59 GMT


ASF GitHub Bot commented on CXF-6343:

Github user coheigea commented on the pull request:
    I just downloaded the patch and applied it via "git apply". I wasn't aware that this removed
the author. I guess I should have used "git am" instead...apologies.

> EncryptedHeader not properly processed or generated
> ---------------------------------------------------
>                 Key: CXF-6343
>                 URL:
>             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("",
"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

View raw message