Hi Fred,
Yes, making some changes in WSSecEncrypt, EncryptionAction and
SignatureAction to process WSEncryptionPart instance allow us to process
Signature over EncryptedData elements. Hence, in the message
ReferenceList in Signature element refers to the wsu:id of the right
EncryptedData element. I tested it with a sample which Encrypts and then
Sign a Timestamp.
This helps to process both Action="Signature Encrypt" and
Action="Encrypt Signature" configuration options, when both EncryptParts
and SignParts are referring to the same element. In context of
WS-Security Policy, thus above change make us support "ProtectionOrder -
SignBeforeEncrypting and EncryptBeforeSigning".
With Regards,
Mayank
Mayank Mishra wrote:
Hi Fred,
Yes, sounds interesting. But consider a scenario when I have
Sign-Encrypt-Sign or Encrypt-Sign-Encrypt to be done, then the same
interceptor need to added twice (before and after the other one). A
solution to this will be to see all Actions beforehand and then repeat
adding interceptors for repeated Actions accordingly. Also since, we
are seeking a generic solution, IMO this will be a bit overhead. Also,
each designated WSS4JInterceptors will have their own data structures
(cryptos, etc) leading to high memory overhead.
The trade-off in the other solution (tweaking SecurityAction,
EncryptionAction) is that we have to change WSS4J code.
But, a solution to this issue will provide support for ProtectionOrder
(SignBeforeEncrypting and EncryptBeforeSigning in WS-Security Policy
spec), though not a concern right now.
What are you thoughts?
With Regards,
Mayank
Fred Dushin wrote:
I see, interesting.
In order to do this in a way that does not require a change to CXF,
perhaps what you could do is split your encryption and signature
actions into 2 separate interceptors, and add a third in between,
which peeks at the result of the encryption action (the results
object will be on the message), and then programatically configures
the WS4JOutInterceptor, which will do the signature action for you.
-Fred
On Jan 23, 2008, at 12:41 AM, Mayank Mishra wrote:
Hi Fred,
Yes, you are right. I am talking about the scenario when we have
multiple EncryptedData elements and I want to sign only one of them.
Yes, I agree XPath would have been much better to handle such scenario.
But AFAIK, we can specify parts (WSEncryptionPart) during
SignatureAction by initializing part structure with element Id (I
guess it is wsu:id, which we can get from map populated during
encryptionAction).
I am yet to test it. I will let you know about it.
With Regards,
Mayank
Fred Dushin wrote:
Hi Mayank,
When you say "one way to achieve this is to specify the URI of the
EncryptedData", do you mean QName, instead of URI?
I get the sense from what you are saying that your message may have
multiple EncryptedData elements in it, and you want to sign one,
but not others. Is that right?
If you have only one EncryptedData, then you should be able to
direct the WSS4J toolkit to sign it, by specifying the
EncryptedData QName, in configuration of the interceptor.
Unfortunately, WSS4J does not provide XPath support for protecting
(signing/encrypting) message parts, so using QNames is inherently
ambiguous.
-Fred
On Jan 18, 2008, at 2:24 AM, Mayank Mishra wrote:
Any reply to this thread will be highly appreciated.
Thanking in advance,
With Regards,
Mayank
Mayank Mishra wrote:
Hi,
Usually we use, Sign and then Encrypt action for any particular
xml element. If I want to use Encrypt and then Sign for a
particular xml element, then SignatureAction fails to find the
xml element. The reason is it has been encrypted and hence
corresponding EncryptedData element will be there.
One way to achieve this, is to specify, URI of EncryptedData
itself in the signature parts. (It should work, though I haven't
tested it). But this is not a full proof solution if I want only
specific element only to be encrypted and eventually signed.
*Is there any mechanism to achieve this?* The only way I can
think of achieving this is to maintain a list of wsu:id's of
corresponding EncryptedData elements and add URI of them to
Signature Parts during .SignatureAction. This may be performed in
adding another interceptor which handles the message after
encryption has been done.
Please let me know your views/suggestions about this.
Thanking in advance. :)
With Regards,
Mayank