Layer7 API Management

  • 1.  SOAP MTOM and Layer 7

    Posted Mar 24, 2015 10:21 AM


    Hi All,

     

    I am wondering if anyone has used CA API Management (Layer 7) for SOAP MTOM requests.

     

    I created a SOAP service policy using the policy manager. I am able to send a non-MTOM soap request to this service policy and it works fine. However, when I send a MTOM soap request, the response sent back is:

     

    l7:policyResult status="Service not found. The request may have been sent to an invalid URL, or intended for an unsupported operation." - It's almost as if the MTOM encoding is making the request invisible to Layer 7 or something.

     

    I've tried to create a separtate non-Soap service policy to understand if the problem is with the 'type' of service, but I receive the same response as above.

     

    Layer 7 includes policy assertions for encoding and decoding MTOM, so I believe Layer 7 can receive soap MTOM requests, but I am at a loss as to how to configure a service to accept MTOM. Does anyone on this forum have any experience with soap MTOM and layer 7? If so, please help.

     

    Thanks in advance.

     

    -Rob C.



  • 2.  Re: SOAP MTOM and Layer 7
    Best Answer

    Posted Mar 24, 2015 12:04 PM

    Rob,

         By default when you create a SOAP service the gateway will perform schema validation on the incoming request messages during service resolution.  If the schema as defined by the WSDL does not allow for MTOM attachments then the service resolution engine will consider the request to have not resolved properly (and will check for another service to which the request may resolve).  Under the service properties WSDL tab you can check the box to allow operations not defined by the WSDL, after which resolution for this service will only be determined by the requested url, the same as a simple web api.

         I can also tell from your error response that you don't have a catch-all (/*) service setup yet for 404 resolution.  Because the service resolution engine goes from most specific to least specific it will not cause any conflicts but can beautify the response for 'service not found' and would show you via the audit records a message like 'non-soap request resolved to soap service' indicating an issue with your request that you were trying to send to your soap service that ended up in the catch-all.

     

    Ben Deutsch



  • 3.  Re: SOAP MTOM and Layer 7

    Posted Mar 24, 2015 12:11 PM

    Ben,

     

    How does one setup a catch-all service for 404 resolution?

     

    I’m interested in this.

     

    Thanks,

    Dan



  • 4.  Re: SOAP MTOM and Layer 7

    Posted Mar 24, 2015 12:36 PM

    Dan,

         Its quite easy, I have some other useful tips in my blog:

    CA (Layer7) API Gateway: Hardening the Layer 7 Gateway

     

    Ben Deutsch



  • 5.  Re: SOAP MTOM and Layer 7

    Posted Mar 27, 2018 05:11 AM

    Hi BenDeutsch

     

    If the schema as defined by the WSDL does not allow for MTOM attachments

    This part of your answer sounds like "if the WSDL would be correct it would work without the checkbox". It would be interesting to know how a WSDL can allow MTOM attachments according to API Gateway.

     

    Thanks

    Stephan



  • 6.  Re: SOAP MTOM and Layer 7

    Posted Mar 24, 2015 02:02 PM

    Thank you Ben.

     

    Once I checked the box to allow operations not defined be the wsdl. The request made it through and I was able to decode it using the "Decode MTOM Message" assertion.

     

    It helps to understand what the gateway does once it receives a request. I don't see any high level documentation that would discuss things like what happens to a request once it hits the gateway. Do you know of any documentation like that?

     

    Thanks again for your help.

     

    -Rob



  • 7.  Re: SOAP MTOM and Layer 7

    Posted Mar 24, 2015 02:57 PM

    Rob,

         I don't, and I'm not sure it exists, but someone from CA/Layer7 (like Stephen_Hughes) would know better.

     

    Ben Deutsch



  • 8.  Re: SOAP MTOM and Layer 7

    Posted Mar 24, 2015 10:12 PM

    Please check out the "Understanding the Service Resolution Process" section of the Layer 7 Installation and Maintenance Manual and that gives a pretty comprehensive explanation of how this happens. Hope it helps


    Regards

    Arvind



  • 9.  Re: SOAP MTOM and Layer 7

    Posted Mar 25, 2015 11:39 AM

    It does not appear to have any mention of http method validation and says that upon failure an error message will be returned, however it will in fact try to resolve to other services that match base on uris that contain wildcards in the event of partial matches.  It also does not have any mention of the built in ssg prefix which I have bumped up against on occasion.  Don't get me wrong, you are right Arvind, that does outline the process, but it appears incomplete or out of date to me.

     

    Ben Deutsch



  • 10.  Re: SOAP MTOM and Layer 7

    Posted Mar 25, 2015 12:13 PM

    Service resolution works on 10 pieces for web services -

    1 - ip

    2 - port

    3 - uri

    4 - content-type

    5 - xml parsing

    6 - ws-security parsing

    7 - soap

    8 - wsdl

    9 - namespace

    10 - potentially policy driven if you have something like Require TLS/SSL with Client Authentication

     

    It is roughly those in order.

    1- 3 are pretty obvious for SOAP Web Services.

     

    4 needs to be text/xml if no attachment or multipart-related with text/xml or application/xop+xml for attachments.

     

    5 content needs to be XML parable if it is not you get an Error of content-type text/html with an html response of Bad Request this is not overrideable in policy.

     

    6 if either WS-Signature or WS-Encryption is in inbound then those get checked prior to policy execution meaning CipherData is decrypted if possible and Signature blocks are check. If signatures are invalid you get a soap fault with Bad Request in details. If encryption key is not found cipher data is not decrypted. These are only overrideable if you chose the properties of the Service and uncheck WS-Security checks on the main tab

     

    7 must be the version of soap that was in the WSDL and that you are enforcing on the WSDL tab of the Service Properties

     

    8 must be a method within the wsdl and optionally the HTTP Header SoapAction is checked against the method as well

     

    9 namespace of inbound must match -  this is how you version a service from v1 to v2 to ... vN with namespaces changes

     

    10 your policy does not have to start with Require TLS/SSL with Client Auth - you can actually have other assertions that do just Require TLS/SSL and Require HTTP Basic and if HTTP Basic is not present then require Client Auth on the TLS/SSL. This is more policy, but since it happens on the protocol setup I put it in here

     

    Service resolution works on 3 pieces for web apis -

     

    1 - ip

    2 - port

    3 - uri

     

    1 and 2 are obvious

     

    3 is where all the action happens. in web apis you will have different web apis with similar uris with wild cards like

     

        a  - /app*

        b - /app/customer*

        c - /app/customer/region/*

        c - /app/portfolio*

        d - /*

     

    So the rule of thumb here is the most closely matched is the policy that prevails. So If I send in /app/customer/1 matches "b" where /app/customer/region/west would match "c" and /app would match "a" and /application would match "d"