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 Fri, 10 Apr 2015 09:46:12 GMT


ASF GitHub Bot commented on CXF-6343:

GitHub user spark404 opened a pull request:

    CXF-6343 Support and parse EncryptedHeader

    SOAP Message Security 1.1 paragraph 9.3 mentions that EncryptedHeader is recommended to
be used when a header part is encrypted. Recent .NET implementations do this and for interop
CXF needs to be able to handle this. WSS4J already does, this fix will make CXF pass the right
information on to WSS4J

You can merge this pull request into a Git repository by running:

    $ git pull CXF-6343

Alternatively you can review and apply these changes as the patch at:

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #64
commit 85c374f962ad317be93471be02b08b3d16d09ebe
Author: Hugo Trippaers <>
Date:   2015-04-10T08:29:06Z

    [CXF-6343] Add test cases to validate handling of EncryptedHeader tags

commit c67e61626d50528fadb94dba6318d435f0e8a9ee
Author: Hugo Trippaers <>
Date:   2015-04-10T08:30:07Z

    [CXF-6343] Change Element to Header for header parts that should be encrypted


> 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