Topic
  • 5 replies
  • Latest Post - ‏2009-04-02T08:23:50Z by terza
terza
terza
139 Posts

Pinned topic Out of memory error when digitally signing larger messages

‏2009-03-30T11:29:49Z |
Is there any general size limits for doing digital signatures with datapower?

We are starting to get "Out of memory" (sign-wssec.xsl)errors when trying to sign ~100MB files. Otherwise the load is very small and there is only one concurrent operation running. I would think DataPower should be able to handle this size files.

So its a XI50 device and a XML Firewall.
It takes an xml document as the input and:
1. digitally signs the xml
2. base64 encodeds the xml and places it inside a soap message
3. digitally sign the soap message (ws-security)

Its the third step that seems to cause the out of memory error.
Updated on 2009-04-02T08:23:50Z at 2009-04-02T08:23:50Z by terza
  • SystemAdmin
    SystemAdmin
    6772 Posts

    Re: Out of memory error when digitally signing larger messages

    ‏2009-04-01T04:49:13Z  
    Hi,

    From the high level scenario you describe, there should not be any issues. There must be something unique in the way it's configured that is causing an issue. Have you set up streaming? The best way forward is to open a PMR on this.

    Thanks,

    Matt
  • SystemAdmin
    SystemAdmin
    6772 Posts

    Re: Out of memory error when digitally signing larger messages

    ‏2009-04-01T06:19:50Z  
    Can you be more specific about the errors experienced? Are these errors in the log? What exactly is the error message?

    Although 100MB as an input is not overwhelmingly large - it is completely possible to create a security processing policy (like the one you describe) that will take that 100 MB and expand it to something significantly larger consuming a lot of memory on the device. For example, your policy as described:

    100 MB XML input
    1. digitally signs the xml = Creates another multi-step context with XML input = 200 MB
    2. base64 encodes the xml and places it inside a soap message = 4:3 expansion of data to base64 encode + creates a new multi-step context with SOAP message = at least 333 MB, maybe 433 MB (depending on the treatment of the data for base64 encoding in XSLT).
    3. digitally sign the soap message = 466 MB, maybe 566 MB to create another multi-step context with the output WS-Security signed message

    So you must be careful because the power of multi-step gives you the ability to copy/expand a large amount of data many times in the same process flow.

    My first suggestion would be to separate out these steps into individual atomic transactions with a loopback service, just to see if there is even a problem with any of the individual steps or if your problem is the combination of actions in multi-step. If you find a problem with an individual step, file a PMR with IBM support to investigate. If you don't find any problems with the individual steps then start looking at how to optimize your multi-step policy. I would recommend looking at the product documentation on the PIPE context for multi-step processing.

    The other question is - because you are trying serialize the entire content of a Base64 encoded message into one XML node maybe you are running into a XML DOS limitation in the parser limits. Remember that in addition to the maximum overall size of a message, there are also configurable limits to the size of nodes within the XML and there is a pretty good chance that the "Out of memory" error is just a generic error to indicate that you have exceeded the per node limit in your XML. I am not even 100% sure that a 100+ MB node is possible, which brings me to the next question...

    WHY are you signing the message, Base64 encoding it, and then signing it again? Does the second signature provide some kind of data integrity that the first one doesn't? And why Base64 encode the original message into a single node? These seem to be very out of the ordinary requirements so maybe we can help you design a more streamlined solution to meet your core requirements.

    Hope this helps,
    Corey
  • terza
    terza
    139 Posts

    Re: Out of memory error when digitally signing larger messages

    ‏2009-04-01T08:32:43Z  
    Can you be more specific about the errors experienced? Are these errors in the log? What exactly is the error message?

    Although 100MB as an input is not overwhelmingly large - it is completely possible to create a security processing policy (like the one you describe) that will take that 100 MB and expand it to something significantly larger consuming a lot of memory on the device. For example, your policy as described:

    100 MB XML input
    1. digitally signs the xml = Creates another multi-step context with XML input = 200 MB
    2. base64 encodes the xml and places it inside a soap message = 4:3 expansion of data to base64 encode + creates a new multi-step context with SOAP message = at least 333 MB, maybe 433 MB (depending on the treatment of the data for base64 encoding in XSLT).
    3. digitally sign the soap message = 466 MB, maybe 566 MB to create another multi-step context with the output WS-Security signed message

    So you must be careful because the power of multi-step gives you the ability to copy/expand a large amount of data many times in the same process flow.

    My first suggestion would be to separate out these steps into individual atomic transactions with a loopback service, just to see if there is even a problem with any of the individual steps or if your problem is the combination of actions in multi-step. If you find a problem with an individual step, file a PMR with IBM support to investigate. If you don't find any problems with the individual steps then start looking at how to optimize your multi-step policy. I would recommend looking at the product documentation on the PIPE context for multi-step processing.

    The other question is - because you are trying serialize the entire content of a Base64 encoded message into one XML node maybe you are running into a XML DOS limitation in the parser limits. Remember that in addition to the maximum overall size of a message, there are also configurable limits to the size of nodes within the XML and there is a pretty good chance that the "Out of memory" error is just a generic error to indicate that you have exceeded the per node limit in your XML. I am not even 100% sure that a 100+ MB node is possible, which brings me to the next question...

    WHY are you signing the message, Base64 encoding it, and then signing it again? Does the second signature provide some kind of data integrity that the first one doesn't? And why Base64 encode the original message into a single node? These seem to be very out of the ordinary requirements so maybe we can help you design a more streamlined solution to meet your core requirements.

    Hope this helps,
    Corey
    Hi csobie and thanks for the extensive response.

    This XML firewall is already in loopback mode and I am using the PIPE context for all actions.

    Its not a XML DOS limitation, I have 256MB as the maximum node size. The exact error message is:
    11:30:04    multistep       error   277074  >    194.211.1.17    0x80c00009      xmlfirewall (SignerFirewall): request SignerFirewall_new_Rule_0 #4 xform: 'Transforming PIPE with store:///sign-wssec.xsl results stored in OUTPUT' failed: Out of memory
    11:30:04        xslt    error   277074  >    194.211.1.17    0x80c00010      xmlfirewall (SignerFirewall): Execution of 'store:///sign-wssec.xsl' aborted: Out of memory
    


    This service is only used to generate requests for our actual business service. 100 MB is not the the average size request (or even close) but we must be prepared for requests that are this large and preferably for even more.

    Structure of the service can not be changed because its sort of a national standard. The rationale behind the structure is the following (in short):
    • Create 2 different roles, "message deliverer" and "customer"
    • One "message deliverer" can deliver messages from several "customers"
    • SOAP is the transport layer and the base64 encoded XML is the actual business payload
    • Separate the authentication and authorization for these 2 roles (=two digital signatures)
    Updated on 2014-03-25T03:50:45Z at 2014-03-25T03:50:45Z by iron-man
  • SystemAdmin
    SystemAdmin
    6772 Posts

    Re: Out of memory error when digitally signing larger messages

    ‏2009-04-01T13:37:35Z  
    • terza
    • ‏2009-04-01T08:32:43Z
    Hi csobie and thanks for the extensive response.

    This XML firewall is already in loopback mode and I am using the PIPE context for all actions.

    Its not a XML DOS limitation, I have 256MB as the maximum node size. The exact error message is:
    <pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">11:30:04 multistep error 277074 > 194.211.1.17 0x80c00009 xmlfirewall (SignerFirewall): request SignerFirewall_new_Rule_0 #4 xform: 'Transforming PIPE with store:///sign-wssec.xsl results stored in OUTPUT' failed: Out of memory 11:30:04 xslt error 277074 > 194.211.1.17 0x80c00010 xmlfirewall (SignerFirewall): Execution of 'store:///sign-wssec.xsl' aborted: Out of memory </pre>

    This service is only used to generate requests for our actual business service. 100 MB is not the the average size request (or even close) but we must be prepared for requests that are this large and preferably for even more.

    Structure of the service can not be changed because its sort of a national standard. The rationale behind the structure is the following (in short):
    • Create 2 different roles, "message deliverer" and "customer"
    • One "message deliverer" can deliver messages from several "customers"
    • SOAP is the transport layer and the base64 encoded XML is the actual business payload
    • Separate the authentication and authorization for these 2 roles (=two digital signatures)
    So back to my list of suggestions. Can you break down your policy into individual steps and run them independently? Send a 100 MB message and have a loopback service digitally sign it. Capture the output off device. Then send the results from step 1 and have the service Base64 encode and wrap it with SOAP. Save the results off device. Finally, send the results from step 2 to the service to sign with WS-Sec.

    What I am trying to determine is if the out of memory is isolate to one specific step (the error message would seem to indicate it is in the last step) or if it is a function of the combine policy.

    Corey
  • terza
    terza
    139 Posts

    Re: Out of memory error when digitally signing larger messages

    ‏2009-04-02T08:23:50Z  
    So back to my list of suggestions. Can you break down your policy into individual steps and run them independently? Send a 100 MB message and have a loopback service digitally sign it. Capture the output off device. Then send the results from step 1 and have the service Base64 encode and wrap it with SOAP. Save the results off device. Finally, send the results from step 2 to the service to sign with WS-Sec.

    What I am trying to determine is if the out of memory is isolate to one specific step (the error message would seem to indicate it is in the last step) or if it is a function of the combine policy.

    Corey
    I started by splitting the service in to 2 pieces:
    1. xml-signature and base64 encoding
    2. SOAP signature

    By doing this im able to process over a request that is over 160MB (which is the largest test material I have at hand now).

    So now when we know this, do you think there is any tricks to make the policy work in one piece?

    Is there anything else that needes to be done related to streaming than using the PIPE context? I tested with default-attempt-streaming XML-manager but its not possible to use that because for example datapowers sign-wssec.xsl wont compile (among others things that I might be able to fix in my application).