9 Replies Latest reply on Dec 22, 2011 8:58 PM by 882069

    MTOM combined with WS-Security (XML signature)

    wsalembi
    wsalembi Sep 22, 2011 7:45 AM
      I'm testing the support of MTOM together with WS-Security (XML-DSIG) on OEG. When verifying the XML signature I noticed I had to add the "Insert MTOM attachments"-filter first. Is this the right way? Shouldn't the signature verification do this transparently?

      My other question is how OEG handles the attachments? Does it page them to disk? What happens if my attachments are very large? With the default setup of OEG I encountered out-of-memory issues with attachments above 200MB

      Edited by: wsalembi on Sep 22, 2011 12:45 AM
      • 4590 Views
      • Tags:
        • 1. Re: MTOM combined with WS-Security (XML signature)
          882069
          882069 Sep 22, 2011 7:57 AM (in response to wsalembi)
          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:

          <SystemSettings
          tracelevel="&server.tracelevel;"
          tracecomponent="&server.title;"
          title="&server.title;"
          homedir="$VINSTDIR"
          secret="&server.entitystore.secret;"
          servicename="&server.servicename;"
          spilltodisk="8388608"
          />
          • 2. Re: MTOM combined with WS-Security (XML signature)
            wsalembi
            wsalembi Sep 22, 2011 8:58 AM (in response to 882069)
            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
            at java.lang.StringCoding$StringDecoder.decode(StringCoding.java:133)
            at java.lang.StringCoding.decode(StringCoding.java:173)
            at java.lang.StringCoding.decode(StringCoding.java:185)
            at java.lang.String.<init>(String.java:571)
            at java.lang.String.<init>(String.java:594)
            at com.vordel.circuit.mtom.MTOMInliner.insertMTOMInline(MTOMInliner.java:80)
            at com.vordel.circuit.mtom.InsertMTOMAttachmentProcessor.invoke(InsertMTOMAttachmentProcessor.java:60)
            at com.vordel.circuit.CircuitInvocation.invokeFilter(CircuitInvocation.java:162)
            at com.vordel.circuit.CircuitInvocation.runCircuit(CircuitInvocation.java:123)
            at com.vordel.circuit.CircuitInvocation.processMessage(CircuitInvocation.java:264)
            at com.vordel.circuit.SyntheticCircuitChainProcessor.invoke(SyntheticCircuitChainProcessor.java:27)
            at com.vordel.dwe.http.HTTPPlugin.invokeDispose(HTTPPlugin.java:197)
            at com.vordel.dwe.http.WebServicePlugin.invokeDispose(WebServicePlugin.java:103)
            at com.vordel.dwe.http.HTTPPlugin.invoke(HTTPPlugin.java:121)

            ERROR 21/Sep/2011:15:31:14.786 [0be4] error handling connection: error reading from remote '127.0.0.1:incoming'
            • 3. Re: MTOM combined with WS-Security (XML signature)
              882069
              882069 Sep 22, 2011 10:10 AM (in response to wsalembi)
              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
              -->
              <ConfigurationFragment>

              <VMArg name="-Xms1024m" />
              <VMArg name="-Xmx1024m" />


              </ConfigurationFragment>
              • 4. Re: MTOM combined with WS-Security (XML signature)
                wsalembi
                wsalembi Sep 22, 2011 11:00 AM (in response to 882069)
                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.
                • 5. Re: MTOM combined with WS-Security (XML signature)
                  882069
                  882069 Sep 22, 2011 11:29 AM (in response to wsalembi)
                  You shouldn't need to inline the attachments
                  • 6. Re: MTOM combined with WS-Security (XML signature)
                    wsalembi
                    wsalembi Sep 22, 2011 2:21 PM (in response to 882069)
                    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?
                    • 7. Re: MTOM combined with WS-Security (XML signature)
                      882069
                      882069 Sep 22, 2011 3:31 PM (in response to wsalembi)
                      Can you switch trace level to DATA and send the resulting trace file to support@vordel.com
                      • 8. Re: MTOM combined with WS-Security (XML signature)
                        hablutzel1
                        hablutzel1 Dec 22, 2011 3:36 PM (in response to wsalembi)
                        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
                        • 9. Re: MTOM combined with WS-Security (XML signature)
                          882069
                          882069 Dec 22, 2011 8:58 PM (in response to hablutzel1)
                          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:

                          http://www.w3.org/TR/xop10/#package_integrity

                          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.