[
https://issues.apache.org/jira/browse/WSS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13622762#comment-13622762
]
Marc Giger commented on WSS-430:
--------------------------------
Hi Nathan,
* 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.
Yes, it's possible (I did it this way in V1) but I was not happy with it and
dropped it. This, the API to WSS4J, is one of the open points which have to be
discussed.
* 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)?
Yes, I think it should work if the assumption is given.
* 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?
Maybe, maybe not;-) I think I've done it this way because attachments are in a
technically sense nothing else than other signature references. In a perfect
world the attachments should most probably be returned as Reference-Objects
from the
call to addReferencesToSign() so that the attachment must not be passed again
to the computeSignature() method.
My prototype is just a proof-of-concept (to discuss the API and such) and far
away from a clean implementation. I will
not commit such ugly code:-) I'm working on some refactoring in WSS4J to be
able to integrate SwA in a
more clean and less intrusive way...
* 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 think you have to look at the mimetype of the attachment and if it's text/xml
or something equivalent then you have to do
the c14n. The preparation for C14n is actually done in the
addReferencesToSign() method and the concrete c14n and digesting deep inside
computeSignature(). Btw, if you take a look at the santuario classes (and
test-classes) you will
find some code for external references (HttpResolver, FileSystenResolver, etc).
Attachment are external references and needs an equivalent handling. Btw2, are
you aware of the
http://docs.oasis-open.org/wss/oasis-wss-SwAProfile-1.1#Attachment-Complete-Signature-Transform
? I don't know which transform your project requires but just to let you
know...
I hope my answers are useful.
Thanks,
Marc
> 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]
