[
https://issues.apache.org/jira/browse/WSS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997340#comment-12997340
]
Colm O hEigeartaigh commented on WSS-254:
-----------------------------------------
Hi Marcin,
I don't view it as the job of WSEncryptionPart to evaluate XPath expressions to
locate elements. It's the job of the calling code to do that, and populate the
WSEncryptionPart list accordingly. The patch I applied was just a way of
clearing a security hole, in that the user might specify an (ambiguous)
localname/namespace, thinking that all matching elements would get processed.
For example, see the "getElement" method in this CXF class:
http://svn.apache.org/viewvc/cxf/trunk/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/AbstractBindingBuilder.java?view=markup
It evaluates a list of Xpath expressions, and stores each found element in a
WSEncryptionPart. This is eventually passed to WSS4J for signature/encryption
etc.
Colm.
> Encryption/signing of multiple message parts with same name not working
> -----------------------------------------------------------------------
>
> Key: WSS-254
> URL: https://issues.apache.org/jira/browse/WSS-254
> Project: WSS4J
> Issue Type: Bug
> Components: WSS4J Core
> Affects Versions: 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9, 1.5.10, 1.6
> Environment: all. (found out an a windows vista machine with java 1.6)
> Reporter: Marcin Markiewicz
> Assignee: Colm O hEigeartaigh
> Priority: Critical
> Fix For: 1.6
>
> Attachments: WSSecEncrypt.java, WSSecEncrypt.java, WSSecEncrypt.java,
> patch.txt
>
>
> The current implementation of the class "WSSecEncypt" lookf in the document
> to encrypt for elements only by their name and namespace (this are the only
> informations provided by the class "WSEncryptionPart"). The search find the
> first element with this name and lets encrypt it. If there are other elements
> with the same name we wish to encrypt it cannot be done. But it is needed if
> one uses lists of elements
> Following example shows the issue:
> <xml...>
> <soapenv:Envelope>
> <soapenv:Header>
> <myNS:Header1>
> <!-- XML data-->
> </myNS:Header1>
> <myNS:Header2>
> <!-- XML data-->
> <myNS:attachment>
> <!-- some data we don't wish to encrypt -->
> <myNS:attachment>
> </myNS:Header2>
> ...
> <myNS:Attachments>
> <myNS:attachment>
> <!-- 1. binary data base64 encoded -->
> </myNS:attachment>
> <myNS:attachment>
> <!-- 2. binary data base64 encoded -->
> </myNS:attachment>
> <myNS:attachment>
> <!-- 3. binary data base64 encoded -->
> </myNS:attachment>
> ...
> </myNS:Attachments>
> ...
> <myNS:HeaderX>
> <!-- XML data-->
> </myNS:HeaderX>
> </soapenv:Header>
> <soapenv:Body>
> <!-- XML data-->
> </soapenv:Body>
> </soapenv:Envelope>
> if we use the WSEncyrpionPart this way:
> WSEncryptionPart encryptionPart = new WSEncryptionPart("attachment",
> "myNS-URI", "Content");
> then only the element "Envelope/Header/Header2/attachment" will be encryptet.
> Thus the one we don't want to encrypt, but the other ones will not be
> encrypted.
> To solve this problem a XPath support in WSEncryptionPart and WSSecEncryption
> is to be implemented (and maybe more...)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
