Logic Apps are the new kid on the block. A service that can be viewed as IFTT (IF This Then That) delivering a simple way of building a workflow. The value Logic Apps offer is automating a chain of services such as Azure Services and/or SaaS uses a wide variety of connectors. Compared to its Citizen Integrator Cousin Flow, Logic Apps are more advanced and requires an integration specialist.
A Logic App can be made directly accessible using an HTTP action, HTTP WebHook or Request/Response Trigger/Action. It will be triggered by a REST type call i.e. METHOD like GET or POST. The HTTP Trigger and HTTP WebHook support authentication using login yet with a HTTP Request trigger the authentication has been provided by a SAS signature in the query string. The latter can be considered less secure as the signature can be sniffed as it is exposed in the query string.
A more secure way for an HTTP Request trigger in a Logic App can be restricting the incoming IP address using API Management. The only IP address allowed to call the HTTP Request trigger generated address, is a specified API Management instance with an known IP address.
In this blog post we will describe how to secure a Logic App with a HTTP Request trigger. We will use the Logic App from a previous post Building a composite service using Logic Apps and tighten the security using API Management.
The scenario is as follows: we will connect with different API’s in a certain order to automate more of a business process or if this (a city) then (weather) that (event).
A Logic App will be a composite service that, based on a set of parameters, will provide a result containing weather and event details. The parameters will be city (IF) for which you like to know the details about the weather the coming 7 days (THEN) and events in that time frame (THAT). The Logic App will call two API’s hosted in API Management, and combine the result of each call into one single response to the client. The complexity of calling the API’s is abstracted away in API Management, and the composition of the response of both API’s is done in the Logic App.
The Logic App access is limited to the IP address of the API Management, only allowing a certain instance of that service access. An API definition is created in API Management with a policy to control the build up of the query string including the SAS signature.
We will restrict access to the Logic App by IP address, which can be configured in Azure Portal. In the settings part of the Logic you can find Access control configuration. Here you can configure the IP addresses allowed to access the Logic App. In the Allowed inbound IP addresses drop down list we select Specific IP ranges. Subsequently you specify the IP address range.
The IP address of the API Management instance can be found by navigating to our API Management instance and in the overview pane/view we can find the address.
The IP address is assigned to an API Management instance once it provisioned.
We want to further tighten the security of our Logic App using API Management. In the previous section, we discussed how to limit access to the Logic App by IP address i.e. the address of our API Management instance. Now we will define an API definition as a gateway to our Logic App and applying a policy to control query string build up.
The screenshot above shows the settings of our API definition i.e. the name, endpoint address of our Logic App, URL scheme and actual Web API URL. To call the Logic App Endpoint we will not call the generated HTTPS address, but the Web API URL. Notice that the Web service URL is not complete. We stripped a part of it to be set on a policy. The generated address of the endpoint in the Logic App is:
And we stripped the part after paths. The invoke will be the operation of our API i.e. URL template, meaning it will be appended to https://prod-11.westeurope.logic.azure.com/workflows/a814659b62ca4b7e80948609eb660c2d/triggers/manual/paths/ next to the part ?version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=QI5mm7-bq4IBWXllzWdX9m0QuwfCxpkVRiRyAp5N45U that will be created by the policy.
The policy on our operation is a set-query-parameter on the inbound call as shown below.
Each part of the query string is specified in the policy and appended to each other to have the full string.
We have our Logic App configured with a limitation of the IP address allowed to call the endpoint. When we call the endpoint with Postman, we will expect to see authorization failed message.
The screenshot above shows what we expected, the client IP address from which we call the Logic App Endpoint is not allowed. Next step is to call the API Management endpoint https://enterprisea.azure-api.net/invoke including specific header types i.e. content type, which should be application/json for the payload we are including in our request and API Management Key (Ocp-Apim-Subscription-Key). The latter is required to be allowed to access the API we created (MyLogicApp).
Now we are seeing that the call is allowed as we receive a response back containing information we wanted. What will be of interest to you, is what happens in the background or behind the scenes in API Management. The request is sent to the API Management endpoint https://enterprisea.azure-api.net/invoke and is then forwarded to the Logic App endpoint. In the developer portal of our API Management instance, we can test the API MyLogicApp. When testing the API, we can inspect what happens with the trace capability. In the Inbound trace flow, we observe how the policy is applied to build up the address i.e. endpoint for the incoming request to be forwarded to.
The backend trace looks like the screenshot below.
The result of the request is the same as the test using Postman.
A Logic App with a Request HTTP trigger will have an endpoint secured by default with HTTPS and a SAS signature (sig=QI5mm7-bq4IBWXllzWdX9m0QuwfCxpkVRiRyAp5N45U). Sending a request to the endpoint could expose complete endpoint address, including the signature, consequently making it vulnerable. In this blog, we showed how to further tighten the security by restricting the access to the Logic by only a range of IP addresses. The access to the Logic App can be restricting this way, or by only allowing other Logic Apps to call it. In general, it should be a good practice to limit access to a Logic App through access configuration feature. Having the Logic App exposed as is i.e. by default is not a sensible thing to do.
By leveraging API Management to control access to the Logic App can be a good option, because not only can you secure the Logic App, you can also enhance other quality of service attributes through policies. The policies offer for example rate limiting. Moreover you can control how many times a consumer can call the Logic App. Furthermore, you can monitor the consumption of the Logic App indirectly, secure access to the MyLogic App API by Oauth 2.0 or OpenID, or other API Management capabilities.
In this post, we have scratched the surface a little on how to enhance security of a Logic App direct access through Request HTTP Trigger. In general, there is a lot more to consider and look into when it comes to securing a Logic App. API Management service in Azure is a valuable asset to increase security of Logic App Endpoints and is one of the easiest services in Azure you can use to secure Logic Apps. In Microsoft docs you can find more information on securing Logic Apps, and Microsoft Azure API Management.
BizTalk360 is used by 650+ enterprise customers in 40+ countries across the globe. With BizTalk360 you can better operate and monitor your Azure Logic apps, service bus queues and API Apps. Our team has worked on the v10 release for close to 1 year to completely refresh the user interface. Also, based on the customer’s feedback from our BizTalk360 feedback portal, some new features were developed. You can get a 30 days trial version of BizTalk360 and explore the product yourself or arrange for a personal demo of the product.
