This content has been marked as final. Show 9 replies
Can you supply trace DATA for the MTOM & XML-DSig scenario?
In relation to your question on attachments, yes the OEG will page to disk. There is a setting, "spilltodisk" that can be placed in the SystemSettings element of the enterprisegateway.xml that specifies the limit of what's considered a reasonable sized message to hold in memory. After this is exceeded, the system will write the content of the incoming request to disk as it arrives, in order to preserve memory. The default cutoff is indeed 4M: If the customer regularly uses messages around this limit, you might consider upping the "spilltodisk" limit to something greater. It's specified in bytes:
I got this stacktrace within OEG (attachment size 100MB). Which other trace data would you like? And where could I find that?
ERROR 21/Sep/2011:15:31:14.504 [0be4] java exception running circuit:
java.lang.OutOfMemoryError: Java heap space
ERROR 21/Sep/2011:15:31:14.786 [0be4] error handling connection: error reading from remote '127.0.0.1:incoming'
The MTOM inliner is attempting to take the contents of the attachment and place them inline in text node in the XML payload.
You can increase the memory of the JVM by placing a file jvm.xml in the /conf directory of your Gateway installation
Contents of jvm.xml:
Additional JVM settings argument that will increase both the min and max memory
JVM memory to 1G (1024m)
Xms = min
Xmx = max
<VMArg name="-Xms1024m" />
<VMArg name="-Xmx1024m" />
I added the inline step to be able to verify the XML signature. Is it absolutely necessary? It seems like a huge drawback to load the entire attachment into memory. The calculation of the digest could easily be done with streaming. What if we have multiple clients sending big files? We can't keep enlarging the JVM memory size.
You shouldn't need to inline the attachments
If I don't inline the attachment, OEG tells me the digest of the SOAP body is incorrect. Does OEG calculate the digest based upon the MTOM attachments or based upon the xop:Include line?
Can you switch trace level to DATA and send the resulting trace file to firstname.lastname@example.org
I'm having problems lately related to this, what does the specification says?? should be the signature be generated over the xop:Include element or over the inlined base64 string?? And is there some java framework can generate the signature over the base64 but send the xop:Include over the wire for performance? I´m looking that CXF 2.3.5 isn't even aware of the difference, if you send MTOM it calculates the signature over the xop:Include and if you disable MTOM it calculates it over the base64 encoded and inlined. Another one, Axis2 if you enable MTOM and WS-Signature always inline the attachment as base64, I would appreciate your help on this topic
If you just sign the <xop:Include> element, you are effectively only signing the reference to the attachment, i.e. the value of the href attribute. This will only prevent someone changing the href to point to a different attachment.
If you in-line the base64 encoded contents of the attachment into the XML message and only sign the base64 encoded string, you are only preventing anyone from changing the contents of the attachment.
You are not stopping somebody from changing what the <xop:Include> href attribute points to.
So I think there is value in signing BOTH the contents AND the <xop:Include> element so that:
- The integrity of the contents of the attachment is ensured, and
- The integrity of the reference to the attachment in the <xop:Include> element is ensured.
Interestingly, the XOP spec acknowledges this issue in Section 6.1:
6.1 XOP Package Integrity
The integrity of Infosets optimized using XOP may need to be ensured. As XOP packages can be transformed to recover such Infosets (see 3.2 Interpreting XOP Packages), existing XML Digital Signature techniques can be used to protect them. Note, however, that a signature over the Infoset does not necessarily protect against modifications of other aspects of the XOP packaging; for example, an Infoset signature check might not protect against re-ordering of non-root parts.
In the future a transform algorithm for use with XML Signature could provide a more efficient processing model where the raw octets are digested directly.
In OEG, it would be possible to use 2 XML Signature Validation filters with an Insert MTOM Attachment filter to validate both signatures.
The flow in the policy would be as follows:
1. 1st XML Signature Filter :- Validate the Signature over the <xop:Include> element
2. Insert MTOM Attachment Filter :- Inline the base64 encoded contents of the attachment
3. 2nd XML Signature Filter :- Validate the Signature over the element now containing the in-lined base64 encoded data.
This policy would ensure the integrity of the attachment contents AND the reference to this attachment in the <xop:Include> element.