[
https://issues.apache.org/jira/browse/WSS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13631500#comment-13631500
]
Nathan Clement commented on WSS-430:
------------------------------------
Hi Marc,
I've had a go at backporting some of your encryption changes to my 1.6.9 source
copy. I'm still using a DataHandler for the attachments rather than direct
references to streams. I got this to work by implementing data sources that
handle the encryption and decryption: AttachmentDecryptionDataSource and
AttachmentEncryptionDataSource. The SOAP library is responsible for replacing
the attachment's DataHandler with the updated DataHandler after WSS4J is
called. I've attached these classes in case they're any use to you (they just
contain your logic from ReferenceListProcessor and WSSecEncrypt). The
AttachmentEncryptionDataSource uses a PushBackInputStream rather than the
anonymous stream class from WSSecEncrypt.setupAttachmentEncryptionStream()
I did note that the API for encrypting is slightly different than for signing.
In signing, a list of attachments is passed to some methods, but in encryption,
the attachment callback is set on the WSSecEncrypt. Would it be possible to
use the callback from WSSecBase in WSSecSignature so that the list of
attachments didn't have to be passed in?
I conducted some interoperability testing against Metro. I found that Metro
won't process a request if the EncryptedData element for the attachment is
before the EncryptedKey element in the wsse:Security header. The WSS SwA spec
seems to indicate in section 5.5.2 that the EncryptedData element should come
first, but this is not reflected in the example in section 5.5.4. It is also
not reflected in the example in section 7.9.2 of the ebMS spec (ebMS/AS4 is
what I'm implementing btw). I reversed the order of these elements
(EncryptedData after EncryptedKey) and Metro was able to decrypt the message.
I really appreciate these patches you've provided for SwA support. It would
have taken me a lot longer to build this myself without these patches as a
starting point.
Thanks,
Nathan
> Support for secured SOAP attachments
> ------------------------------------
>
> Key: WSS-430
> URL: https://issues.apache.org/jira/browse/WSS-430
> Project: WSS4J
> Issue Type: New Feature
> Components: WSS4J Core
> Reporter: Marc Giger
> Assignee: Marc Giger
> Priority: Minor
> Attachments: AttachmentContentTransform.java, santuario-swa.diff,
> wss4j-swa.diff
>
>
> The attached patches should serve as a basis for discussions how
> the support for SwA in WSS4j and the integration in
> a SOAP-Stack should look like.
> Some notes to the patch:
> - Applies to the current trunk of santuario and wss4j.
> - The client side demonstrates the DOM approach whereas the server side uses
> the StAX implementation.
> - I've implemented the very basic just to have a working proof-of-concept.
> - Attachments are requested via callback from the soap-stack because
> - of decoupling from soap-stack
> - to support full streaming from network to SIB as far as possible
> - CXF dependencies are just a leftover from V1 and because the
> SecurityInInterceptor is not ported to V2
> - Encryption / Decryption of an attachment is streaming oriented, no
> buffering is done in WSS4J.
> - Signature creation and verification is at the moment buffered in WSS4j but
> the signature-verification can, under some conditions, be streamed as well.
> - To prevent patching of CXF for the prototype the WSS4J Interceptors and
> some dependencies are copied and modified and also included in the patch. The
> santuatio changes are necessary for the StAX impl.
> For DOM all necessary santuario changes are done via reflection or other
> hacks for now.
> Feedback is very welcome and also necessary!
> Thanks,
> Marc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
