How to handle SOAP Faults in XML Schema Validation

[Yannick Carbonneaux]

Hello,

I have a backend webservice which can send back soap fault messages that way: 

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    <soapenv:Body>
        <soapenv:Fault>
            <faultcode>soapenv:Sender</faultcode>
            <faultstring>Unknown Error</faultstring>
            <detail>
                <n:serviceFault> actual error </n:serviceFault>
            </detail>
        </soapenv:Fault>
    </soapenv:Body>
</soapenv:Envelope>

Which is the standard SOAP 1.1 way of sending back errors.

The soapenv:Fault tag is part of the "http://schemas.xmlsoap.org/soap/envelope/" namespace, and not described in the XSD of my service. 

When using the XML Schema Validation assertion to validate responses sent back from my service, my assumption was to validate against the message body, and indicates the XSD of the service which describes all the "n" namespace above (not described here for non-disclosure reasons...). 

But when doing so, the API Gateway sends back a validation error  :

com.l7tech.server.policy.assertion.xml.ServerSchemaValidation: 5604: Schema validation failure: org.xml.sax.SAXParseException; cvc-elt.1.a: Cannot find the declaration of element 'soapenv:Fault'.

This soapenv:Fault tag is indeed not described in the XSD I've put in the assertion. I was expecting this soapenv:Fault tag to be recognized by the assertion, as this is a standard SOAP element.

What am I doing wrong here ?  :) Should I instead validate the entire SOAP message and import the "http://schemas.xmlsoap.org/soap/envelope/" schema instead for this to work ?

Thanks for your help,

Yannick

[Jay MacDonald]

The XSD is explicit. If an element is not described by the XSD then the validation will fail. It does not matter that it is part of SOAP - schema validation is at the XML level, not the SOAP level.

You can try and write a schema that accounts for both your message AND a SOAP fault, but that would be a weak schema IMO. A better approach would be to have a schema that describes your correct response and a second schema that describes SOAP fault. Wrap the validation assertions in an At Least One folder. Note that if it succeeds on the SOAP fault it will pass it through to the client, something that may reduce the security of the service. We recommend that an obfuscated SOAP fault from the Gateway be returned when policy fails, not the SOAP fault from the service which can contain details useful to an attacker. 

[Maurizio Garzelli]

Hi Yannick,

I believe that Jay is on the money there indeed, that is what I would have suggested too: your best bet is to use an "at least one assertion must evaluate to true" assertion and have the original schema validation assertion as is in there as well as a logic that checks the response if the validation fails and decide if there is a need to obfuscate (which as Jay states, is the best practice, to mask any sensitive info about the backend) before returning the error to the client.

I would even go further and state that in case of unexpected failures from the backend, that in that logic you would have some alerting in place, alerting either you and/or the team responsible for the backend so that they are aware that their application is generating a non expected error.

We can talk about options if you want :)

Maurizio