Dynamics 365 quick bites - How to Secure Azure Logic apps HTTP endpoints? Part I

Logic Apps are great but exposing them as publicly available HTTP service is clearly far from perfect. If your logic app uses a request-based trigger, which receives incoming calls or requests, such as the Request or Webhook trigger, you can limit access so that only authorized clients can call your logic app, this article will be very useful to plan and execute security implementation in your Logic Apps endpoints.

For all citizen and core developers that are building Logic App http triggers, here is a brief solution that how we can secure logic apps? but in my continuous article, I will explain that how to make Logic Apps a little further more secure? For this article, I will focus on options available within Logic Apps umbrella. Let's see how?

Azure securely generates logic app callback URLs by using Shared Access Signature (SAS). This signature passes through as a query parameter and must be validated before your logic app can run. Azure generates the signature using a unique combination of a secret key per logic app, the trigger name, and the operation that's performed. So unless someone has access to the secret logic app key, they cannot generate a valid signature.

The problem with the first offering is that SAS token values can be viewed by naked eyes either in the browser or can be traced over network tool very easily as key and value append in request URL as a parameter.

Let's see the second option available in Logic apps workflow settings, you need to navigate from Logic Apps -> Settings-> Workflow settings -> Access control configuration.

Let's focus briefly what does it offer-

1. Any IP- This option is selected by default, this is not secure at all, I will afraid to use this.
2. Only other Logic Apps- This is a valid scenario when you need to call your Logic Apps within your resource group via other Logic Apps, I will explain this option with detail in separate article.
3. Specific IP ranges- Most promising here especially when you need to call a url from outside of the Azure ecosystem.

Lets elaborate 3rd option a bit more here. A valid IP range uses these formats:  x.x.x.x/x or x.x.x.x-x.x.x.x

• An IP address range such as 192.168.1.19-192.168.1.23 (xxx.xxx.xxx.xxx-xxx.xxx.xxx.xxx).
• or a Classless Inter-Domain Routing (CIDR) format like 192.168.1.19/23 (xxx.xxx.xxx.xxx/xx). Classless inter-domain routing (CIDR) is a set of Internet protocol (IP) standards that is used to create unique identifiers for networks and individual devices. CIDR IP addresses consist of two groups of numbers, which are also referred to as groups of bits. The most important of these groups is the network address, and it is used to identify a network or a sub-network (subnet).

I have just changed the Trigger access option to Specific IP ranges as below-

I tried to call my endpoints via Postman and its throw following error with 401 status code, which means no one can longer call this logic app outside of IP range-

Now I have added the IP in the IP range for triggers in workflow settings, like below-

and I have executed my request from postman again, and I have got expected result. Which means now only request from specific IP ranges will be served.

I hope the above information will be useful for understanding and implementation prospect. Stay tuned for Part II, where I will explain how to use Azure API Management service to fully secure Logic App endpoints where requester don't have a static IP assigned. Happy Learning!!