You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Андрей Хайсин <an...@gmail.com> on 2010/02/24 15:54:14 UTC
Securing SOAP attachments
Hello,
My goal is to send binary data as MTOM attachment with signing this
attached data.
I've read a lot that WSS4J does not support signing MTOM attachments
(http://issues.apache.org/jira/browse/CXF-1669 and etc.)
As I understood the sequence of actions should be:
- binary data are inlined in soap:body;
- signign\encription is performed;
- if MTOM enabled binary data are extracted, replaced by XOP:Include
placeholder, added as multipart attachment;
- message is sent ...
And vice-versa on the receiver side
Am I right?
Could somebody help me how to achieve this with WSS4J or without it?
As I understood WSS4JOutInterceptor uses saajOutInterceptor to extract
binary data as MTOM attachments
and only after this perform signing.
So only instead of binary data placeholder (<inc:Include
href="cid:attachments.txt"
xmlns:inc="http://www.w3.org/2004/08/xop/include"/> ) is used for
signing.
--
Best regards!
-------
Andrei Khaisin
mailto:andrei.han@gmail.com
Re: Securing SOAP attachments
Posted by Daniel Kulp <dk...@apache.org>.
There really are two options:
1) Create a patch to WSS4J (and maybe xmlsec/santurio) that would provide a
callback for CXF to provide the data to be signed if they encounter a XOP
node. This is kind of the ideal way to go, but is probably a ton of work.
The advantage here is that, if done right, we could keep gigantic attachments
out of memory.
2) Write some new XMLStreamReader/Writer things that would undo/record the xop
things so the WSS4J interceptors could work with a non-xop SAAJ.
The reading side is relatively easy. On a startElement event, if it's an
Include, don't report the start event, instead, report a text even, grab the
attachment, bas64 it, and return it. The built up SAAJ would have the
attachment as base64 text node that JAXB and others would be able to handle
just fine later. Obviously, that's quite a bit of memory though.
The writing side can be done in one of two ways: (that I can think of, there
are probably more)
1) You'd could write a writer that basically recorded an XPath to all Include
elements that are written. Prior to WSS4J processing, use the XPath to "un-
xop" those elements and then after WSS4J processsing, return them to their
original state.
2) After you get the SAAJ doc, you could use a full XPath to search the SAAJ
for Includes and un-xop/re-xop them as in (1). The full XPath might be a bit
slower though due to it requiring an full search of the entire DOM.
In either case, due to the way WSS4J works, the entire message including the
base64 forms of the attachments would be held in memory while processing. For
large attachments, that could be an issue. Also, since you have to base64
the data anyway, you do loose some of the lower CPU advantages of the mime
attachments. Also, note, if you encrypt as well as sign, the Include elements
could be gone so you wouldn't be able to restore them at which point you would
need to remove the attachments.
If you pursue any of this, we'd LOVE to have it added to CXF. Submit a
patch!
Dan
On Wed February 24 2010 9:54:14 am Андрей Хайсин wrote:
> Hello,
>
> My goal is to send binary data as MTOM attachment with signing this
> attached data.
>
> I've read a lot that WSS4J does not support signing MTOM attachments
> (http://issues.apache.org/jira/browse/CXF-1669 and etc.)
>
> As I understood the sequence of actions should be:
> - binary data are inlined in soap:body;
> - signign\encription is performed;
> - if MTOM enabled binary data are extracted, replaced by XOP:Include
> placeholder, added as multipart attachment;
> - message is sent ...
> And vice-versa on the receiver side
>
> Am I right?
> Could somebody help me how to achieve this with WSS4J or without it?
>
> As I understood WSS4JOutInterceptor uses saajOutInterceptor to extract
> binary data as MTOM attachments
> and only after this perform signing.
> So only instead of binary data placeholder (<inc:Include
> href="cid:attachments.txt"
> xmlns:inc="http://www.w3.org/2004/08/xop/include"/> ) is used for
> signing.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog