Is it possible to use the subscription-key query string parameter with Azure API Management SOAP-passthrough?

2.7k views Asked by At

We use API Management to expose several API's. One of the API's we expose is configured as a SOAP-passthrough API but we are facing some issues with it regarding authentication of APIM.

When we use the Ocp-Apim-Subscription-Key header for passing the query string it all works correct and the API is returning it's content correct.

When we use the subscription-key query string parameter the API is returning a 401 Unauthorized. I tested this behavior in Postman and changing the way of sending the subscription key is resulting in this behavior.

An implementation detail of this API is that it exposes an existing WSDL and routes this SOAPAction to an Azure Function via the policy. In the Application Insights of the function I can verify that the function is never invoked when I get a 401 but it is invoked when I get a successful call (using the header).

Is this normal behavior? Am I doing things wrong? Or is it a bug in APIM?

2

There are 2 answers

0
Wessel Kranenborg On BEST ANSWER

We currently use a workaround around this problem with the following policy. Instead of changing the backend-server url in the policy we send a request and set the response of that request as a response for this api. Below you can find our policy which is working with the subscription-key in the query string.

<policies>
    <inbound>
        <base />
        <send-request mode="copy" response-variable-name="response" timeout="20" ignore-error="false">
            <set-url>{{BackendServer_URL}}</set-url>
        </send-request>
        <!--return-response response-variable-name="reponse" /-->
        <choose>
            <!-- If StatusCode is not OK, return Unauthorized with the reason. -->
            <when condition="@(((IResponse)context.Variables["response"]).StatusCode != 200)">
                <return-response response-variable-name="reponse">
                    <set-status code="401" reason="Unauthorized" />
                    <set-body>@(((IResponse)context.Variables["response"]).Body.As<string>())</set-body>
                </return-response>
            </when>
            <otherwise>
                <return-response response-variable-name="reponse">
                    <set-status code="200" />
                    <set-header name="Content-Type" exists-action="override">
                        <value>text/xml; charset=utf-8</value>
                    </set-header>
                    <set-body>@(((IResponse)context.Variables["response"]).Body.As<string>())</set-body>
                </return-response>
            </otherwise>
        </choose>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>
1
Darrel Miller On

This might be an issue with the way we do routing for SOAP Passthrough. You will notice in the API setup that we add on a query parameter to identify the SoapAction that an operation will be matched to. It may be that your the api key query parameter is getting overwritten when adding the SoapAction parameter to the inbound request. I will investigate and let your know.