Restrict Azure Logic Apps’s workflows access only to Dynamics 365 Business Central.

Some week ago I wrote an article explaining how you can restrict Azure Logic Apps workflows access to certain IP ranges. This can be extremely useful if, for security purposes, you want to control who can access your HTTP-triggered workflows.

After this post, someone asked if it’s possible to restrict access to a workflow only from calls coming from a Microsoft ‘s SaaS business application like Dynamics 365 Business Central. The answer is YES. But how can you do that? Do you need to restrict the access to the Dynamics 365 Business Central IP address, that is absolutely not static? Obviously no…

The best way to do that is to create an incoming rule that grant access to your Azure Logic Apps workflow only for a certain Azure Service Tag. If you remember, in the past I wrote an article announcing that Dynamics 365 Business Central now has an official Azure Service Tag called Dynamics365BusinessCentral, so why not using it for securing your workflows?

Restrict Azure Logic Apps access to an Azure Service Tag.

To show how you can create an inbound security rule for a particular service tag in Azure Logic Apps, I’ve created a simple Logic Apps standard with the following workflow, that simply accepts an incoming HTTP call and performs some actions:

By default, an HTTP-triggered workflow has public network access without restrictions, so anyone that knows the workflow’s url (with key) can trigger it:

To specify an inboud security rule, you need to select the Networking menu in your Azure Logic Apps instance and then click on the Public network access option. Then in the Access Restrictions page, set the rule as follows:

The rule here defines that the traffic is enabled only from selected virtual networks and IP addresses. Then click on Add and create a rule as follows:

Important here is to set Action = Allow and Source Settings = Service Tag. Then from the list of the available Azure Service Tags, select Dynamics365BusinessCentral.

Then save the newly created rule. It will appears as in the following image. As you can see, the incoming traffic is allowed only if it respects our rule, otherwise it’s denied:

To test if the rule is working, I’ve simply created a very basic Dynamics 365 Business Central extension that adds an action that triggers our Azure Logic Apps workflow (by sending a GET HTTP request to the Azure Logic Apps’s workflow’s url):

What happens if I deploy the extension and I execute the action?

The Azure Logic Apps workflow is successfully triggered, because the HTTP call that triggers the workflow is coming from Dynamics 365 Business Central:

If instead I trigger the workflow from outside Dynamics 365 Business Central (sending a GET request to the workflow’s url), the incoming call is forbidden:

Your workflow will be more secure if you start applying this rule. Here I’ve used the Dynamics365BusinessCentral service tag as an example (and to answer the received question), but you can extend this approach to other service tags as per your needs.

P.S. This approach also applies to Azure Functions. You can restrict an Azure Function inbound access to a particular service tag by going to the Settings|Networking option in your function app and set an inbound security rule as previosuly explained:

Original Post https://demiliani.com/2024/10/15/restrict-azure-logic-appss-workflows-access-only-to-dynamics-365-business-central/