[
https://issues.apache.org/jira/browse/WSS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13621429#comment-13621429
]
Nathan Clement commented on WSS-430:
------------------------------------
Hi Marc,
Thanks for providing these patches. My project timelines mean that I will need
this SwA functionality before it's included in a WSS4J release, so I'm porting
some of the changes to my local copy of the 1.6.9 source. So far I've looked
at signature generation - here are some comments/questions:
* Would it be possible to use a DataHandler in the Attachment class instead of
streams? Both Rampart and SAAJ have easy access to a DataHandler for the
attachments.
* In your comments in WSSecSignature you talk about the need to buffer the
attachment content during signing. If I understand correctly, the SOAP
processing will require that the attachment content is read twice - once when
computing the signature and once when writing the final SOAP MIME envelope. If
the Attachment class used a DataHandler, would the buffering of the attachment
content be unnecessary (assuming that you could get the InputStream from the
DataHandler multiple times)?
* I notice that WSSecSignature.prepare() takes the Document as an argument.
Would it make sense to pass the attachments in here instead of passing them to
the addReferencesToSign() and computeSignature() methods?
* Section 5.4.2 of the WS-Security SwA profile talks about canonicalizing XML
attachments. Do you have any thoughts about how that could be achieved?
I realise I'm not a developer on WSS4J, so please feel free to point out if
I've misunderstood anything.
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: 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: [email protected]
For additional commands, e-mail: [email protected]
