[
https://issues.apache.org/jira/browse/WSS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13625039#comment-13625039
]
Nathan Clement commented on WSS-430:
------------------------------------
Hi Marc,
Thanks for your reply - it's very useful.
With regards to buffering the attachments, I see from JIRA that you guys have
done some awesome work to support streaming in WSS4J. This will help us a lot
in the future because the messages we're looking at could be quite large and
not having to have a DOM representation would be great. It would also be great
if there was a way to stream the attachment content for signature/encryption so
that it didn't have to be buffered in memory. DataHandler was one idea I had,
but I agree that it may not be the most appropriate for the public API. I like
the idea that attachments are just other external references.
I've had a go at implementing the canonicalisation of attachments. I ended up
doing it in my custom URIDereferencer when the attachment content type is
text/xml, application/xml or application/soap+xml. The dereferencer parses the
XML into a DOM (since I'm working with 1.6.9) and returns an ApacheNodeSetData
instance. The addReferencesToSign() adds the exclusive canonicalisation
transform to the transforms list.
I am aware of the attachment complete transform. The Axiom API doesn't seem to
provide me with enough MIME header values to implement this, so I'm hoping I
can get away with just using the attachment content transform :) If that
doesn't turn out to be the case, I'll look at patching my local copy of Axiom
to get the extra header values.
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]
