Layer7 API Management

Expand all | Collapse all

Handle Soap Faults

  • 1.  Handle Soap Faults

    Posted Sep 28, 2017 08:12 AM

    Hi,

     

    How can we handle the below soap faults in a single policy

     

    1.Service Not found (raised when incorrect service url is used)

    2. HTTP Method not allowed(raised when given HTTP Method is not allowed for the service) 

     

    I think message-completed global policy can be used here,but how do we differentiate the errors?



  • 2.  Re: Handle Soap Faults

    Broadcom Employee
    Posted Sep 28, 2017 08:50 AM

    Hello, 

     

    We actually have a Customize Error Response assertion, where you can customize the error thrown based on the HTTP Status being returned:

     

    Customize Error Response Assertion - CA API Gateway - 9.2 - CA Technologies Documentation 

     

    Let me know if this is something you're looking for.

     

    -Alec Daniello

    APIM Support



  • 3.  Re: Handle Soap Faults
    Best Answer

    Broadcom Employee
    Posted Sep 28, 2017 09:06 AM

    Just to further answer your questions:

     

    1. You can use what we call a catchall service with the customize error response or return template response. Simply create a service with a resolution url of "/*". This service will be called when the request's url cannot be matched to another service.

     

    Inside that service you can set up a template response or the customize error response (in my reply above) with the content you want to return. 

     

    2. I would lean more towards the message-received policy for the HTTP Method not allowed, but a global policy before or after policy completion would work for this:

     

    Global Policy Fragments - CA API Gateway - 9.2 - CA Technologies Documentation 

     

    I hope this all helps!

     

    -Alec Daniello

    APIM Support



  • 4.  Re: Handle Soap Faults

    Posted Sep 28, 2017 09:47 AM

    Hi Alec,

     

    I already have a catchcall service but what i want is a single policy that can handle both these error scenarios .For that i should be able to differentiate between the two errors using may be compare  expression assertion in my global policy.

    Is there any context variable set for these errors which can be used for comparison?



  • 5.  Re: Handle Soap Faults

    Posted Oct 02, 2017 02:59 PM

    So this /* catch all is always evaluated last during the path resolution process?



  • 6.  Re: Handle Soap Faults

    Posted Oct 05, 2017 02:55 AM

    that's correct



  • 7.  Re: Handle Soap Faults

    Posted Sep 28, 2017 02:41 PM

    For a SOAP service both of these should end up in the catch-all, because soap service resolution requires that the POST payload match the service WSDL and for OPTIONS, GET, HEAD, DELETE, etc. there typically is no request body and therefore it does not resolve to the soap service and instead resolves to non-soap api based on URI resolution, which lands it in the catch-all.  Once the request is there you can triage it, you may loop over the audit.details context variable and see if it contains a message indicating that soap service resolution failed (as seen in the audit viewer details).  However, method not allowed is a bit more difficult.  You would see same message because soap message comparis occurs before http method validation and if it passes messsage validation (or doesn't use it because it is not a soap service) and also URI resolution then when it fails method validation it will not execute the service policy, instead sending a generic L7 error message.

    (for this reason I advise enabling all http methods on all non-soap services then doing method validation within the service)



  • 8.  Re: Handle Soap Faults

    Posted Oct 05, 2017 02:57 AM

    Hi Ben,

     

    This is a REST Service which should return a custom JSON Error response



  • 9.  Re: Handle Soap Faults

    Posted Oct 05, 2017 11:48 AM

    I stand by my previous explanation; service resolution occurs before method validation and if method validation fails then the service policy is not executed and a generic layer7 error message is sent by the gateway.  For this reason I advise enabling all http methods on all non-soap services then doing method validation within the service.

     

    https://communities.ca.com/ideas/235737034-http-method-based-service-resolution



  • 10.  Re: Handle Soap Faults

    Posted Oct 05, 2017 12:59 PM

    Basically, something like this. Right?

    Example



  • 11.  Re: Handle Soap Faults

    Posted Oct 12, 2017 12:40 PM

    yep, exactly; though I use a simple compare (which does accept regex as the test criteria) instead of the regex assertion to check the method

    policy logic



  • 12.  Re: Handle Soap Faults

    Broadcom Employee
    Posted Oct 18, 2017 01:33 PM

    Good afternoon,

     

    Did the suggestions provided address your question?

     

    Sincerely,

     

    Stephen Hughes

    Director, CA Support



  • 13.  Re: Handle Soap Faults

    Posted Oct 24, 2017 04:51 AM

    We have decided to skip this error handling for now since enabling all HTTP Methods for a service and adding extra block of assertion to handle HTTP method is just a workaround and adds unnecessary overhead.



  • 14.  Re: Handle Soap Faults

    Posted Oct 24, 2017 11:49 AM

    revised:

    I would strongly advise to do so as to not leaves generic "L7" error messages (see below) being returned (it does write to the audit log and you can catch it in the message completed global policy fragment... that wouldbe another way to manage them).  As for overhead, I acknowedge that it may cost you ~2ms (don't take my word, try it), however I consider that a reasonable cost to close the security gap.

    Disclosure: I am not CA

     

    20171024 08:54:35.601INFO3021HTTP method PUT not allowed for service Ping

     

    <?xml version="1.0" encoding="UTF-8"?>
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
        <soapenv:Body>
            <soapenv:Fault>
                <faultcode>soapenv:Server</faultcode>
                <faultstring>Error in assertion processing</faultstring>
                <faultactor>https://your.server.url/ping</faultactor>
                <detail>
                    <l7:policyResult
                        status="HTTP method PUT not allowed: https://your.server.url/ping" xmlns:l7="http://www.layer7tech.com/ws/policy/fault"/>
                </detail>
            </soapenv:Fault>
        </soapenv:Body>
    </soapenv:Envelope>