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