Uploaded image for project: 'WSS4J'
  1. WSS4J
  2. WSS-644

Error when a SOAP-Fault is thrown with MTOM enabled

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.2.2
    • 2.2.3, 2.3.0
    • None
    • None
    • Tested with CXF 3.3.0 / WSS4J 2.2.2 on Oracle Java 8.

    Description

      We think we may have found an issue that looks very similar to this Camel one: We use CXF/WSS4J for JAX-WS with JAXB in contract-first mode. We use WebService Security (signature & encryption) and have MTOM serialization enabled per policy using:

          <wsoma:OptimizedMimeSerialization />
      

      Everything seems to work fine when normal responses are generated from our Server. However, when a SOAP-Fault occurs, the CXF client throws a parsing exception like this one (it says: "Prefix "soap" for element "soap:Fault" is not bound"):

      Caused by: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 13; Präfix "soap" für Element "soap:Fault" ist nicht gebunden.
      	at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257)
      	at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:339)
      	at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121)
      	at org.apache.xml.security.utils.XMLUtils$DocumentBuilderProxy.parse(XMLUtils.java:1161)
      	at org.apache.wss4j.dom.util.EncryptionUtils.decryptXopAttachment(EncryptionUtils.java:399)
      	at org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData(EncryptionUtils.java:207)
      	... 49 more
      

      When I debug into decryptXopAttachment at EncryptionUtils.java:399 and look at what bytes it's trying to parse, they look something like this (<detail>'s contents omitted for readability):

      <soap:Fault>
          <faultcode>soap:Server</faultcode>
          <faultstring>4</faultstring>
          <detail>[...]</detail>
      </soap:Fault>
      

      And of course, looking only at the body's contents attached via XOP, the "soap" prefix isn't declared anywhere. It is declared in the <soap:Envelope> element, but since that's not being included in the validation here because the attachment is being validated on its own, that namespace declaration is missing.

      • When we return "regular responses", this error isn't triggered because the "soap" prefix declared in the envelope isn't used in any of the bodie's elements, so all namespaces used in the body are being declared in it.
      • If we disable MTOM, everything works fine - the response message will probably be parsed in its entirety, including the envelope and its namespace declarations.
      • CAMEL-8663 seems to address this very issue on the Camel side (with help of CXF and an endpoint property called org.apache.cxf.binding.soap.addNamespaceContext, used in org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor). We need the same fix for standalone CXF/wss4j usage though.
      • I compared wss4j's behavior to metro/wsit using the same policy and metro includes the envelope's namespaces in the element being attached like so:
        <S:Fault xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
            <faultcode>S:Server</faultcode>
            <faultstring>4</faultstring>
            <detail>[...]</detail>
        </S:Fault>
        

      So my conclusion is that WSS4J/CXF (forgive me if I used the wrong Jira project) should repeat all namespaces declared in the <soap:Envelope> element in the xop-attached body if MTOM serializaiton is enabled.

      Attachments

        Activity

          People

            coheigea Colm O hEigeartaigh
            netmikey Mike M.
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: