Securing, Monitoring and Aggregating Azure Logic Apps with Sentinet API Management

Azure Logic Apps is a cloud-based platform for creating and running automated workflows that integrate your apps, data, services, and systems. One of the most popular means of executing Logic Apps’ workflows is to trigger them by making RESTful API calls and using HTTP Request trigger in combination with Response action. Exposing these APIs via API Management gives numerous benefits. Here are just some of them:

1. Maintaining managed catalog of versioned RESTful APIs that are used to invoke Logic Apps.
2. Securing access to Logic Apps via strong, dynamically managed authentication and authorization, and by wrapping Logic Apps’ own non-standard, often weaker security.
3. Monitoring end-to-end requests and responses to and from Logic Apps with advanced API analytics, reporting and notifications.
4. Aggregating multiple Logic Apps in a single API with a single endpoint and a unified managed security (which is effectively treating Logic Apps as microservices, but without increased complexity added to invoker applications).

In this article I will show few simple examples, which demonstrate these benefits using Sentinet API Management from Nevatech.

First, I will show how Sentinet API Management fits the paradigm of invoking a single Logic App:

Note few points from the simple diagram above:

1. Security of the virtual RESTful API (1) hosted by API Management (APIM) endpoint can be as strong and standard as you want (for example, using username/password, X. 509 certificates, API Keys and/or OAuth/Open ID Connect with any OAuth provider of your choice), while internet-accessible Logic App’s endpoint (2) is secured with non-standard security of Azure Shared Access Signature, which is exposed directly by Logic App’s URL (see below).
2. Security of the virtual RESTful API (1) hosted by API Management (APIM) can be managed with dynamically configured authentication and authorization policies, while Azure Shared Access Signature remains hidden from any application that wants to use Logic App. Moreover, whenever there is a need to regenerate Azure Shared Access Signature, it can be done without affecting applications that use Logic App.
3. API Management can automatically provide detailed end-to-end monitoring and analytics of the messages that fly through APIM to and from Logic App.
4. While Logic App always runs in Azure Cloud, both Application which uses it, and API Management Gateway can be anywhere (for example, you may have them both on-premises, in the cloud, or in hybrid deployment). Think about on-premises application which wants to use a cloud-based Logic App. You can do it safely and effectively if you have on-premises APIM Gateway.

Next, I will extend my simple example to show how API Management further helps applications to deal with multiple Logic Apps. In this case, applications can still use a single endpoint of a single virtual API hosted in APIM Gateway (1), while a single virtual API now will have multiple operations, each effectively representing individual Logic App.

Logic App in Azure Portal

I will start with creating a very simple “Hello Logic App” in Azure Portal, which is triggered by HTTP Request trigger configured to expect an HTTP GET request with the {name} parameter in the URL path. The {name} parameter will be used to echo it back in the Response action’s body. Here is my simple workflow in Azure Portal’s Logic App designer:

The HTTP GET URL highlighted in the workflow designer above is generated by Azure when you save your Logic App for the first time. It includes an auto-generated Shared Access Signature as a sig query parameter, and along with the workflow unique Id is the only (kind of weak!) security protection. For example:

https://prod-91.eastus.logic.azure.com/workflows/9b7dc8e2e20d467f8b11b276c9a21601/triggers/manual/paths/invoke/{name}?api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=aKSI1IpHL-Oyltl6-S_fsBHYC3ystW0245QuAM0asIw

Configuring Sentinet API Management with Logic App

1. Register in the Sentinet Administrative console a physical REST service created in Azure Portal above, which represents entry point into the workflow via its HTTP Request trigger.
1. Register empty API (let’s say named Hello)
2. Add to it an endpoint with address https://prod-91.eastus.logic.azure.com/workflows/9b7dc8e2e20d467f8b11b276c9a21601/
   triggers/manual/paths/invoke and security policy REST – HTTPS.
   
   Notice, that endpoint address ends just before /{name}... begins. The rest of the URL will be part of request’s URI template configuration.
3. Add operation (let’s say called SayHello) with Method GET and Request’s URI template specified as /{name}?api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=aKSI1IpHL-Oyltl6-S_fsBHYC3ystW0245QuAM0asIw
   
   Notice, that Sentinet automatically populates Parameters table once you enter URI Template field.
4. Now the full URL to SayHello operation automatically becomes exactly as HTTP GET URL of the Logic App’s HTTP Request action.
   
5. Using Sentinet drag-and-drop UI virtualize this physical API through a Sentinet Node (API Gateway) as let’s say VHello virtual service.
   
6. Click Modify Request button highlighted above to create a non-default mapping between Virtual Request and Virtualized Request. What I would like to do here is to remove (hide) everything but the {name} parameter from the virtualized request. Effectively, security of an Azure Shared Access Signature secret will be removed from the knowledge of the application, which calls Logic App via Sentinet. Moreover, just to show additional flexibility of Sentinet, I will make the {name} parameter to be a query parameter rather than a URL path parameter of the original physical API.
   
7. Now virtual VHello RESTful service has very simple invocation URL, https://sentinet/NodeAsp/helloLogicApp/?name={name}, which is hosted in Sentinet Node (API Gateway).
   
   Notice, that using Sentinet’s drag-and-drop UI and Request Message Details dialog box, takes less than a minute to create entire VHello service.

When it comes to the inbound endpoint of the virtual service hosted in Sentinet Node (API Gateways), I can now configure it with whatever standard and strong security that I want. This process is completely independent from everything else that was done so far here. Effectively, I can expose my Logic App to consumers with any authentication scheme and authorization rules – all driven by the Sentinet User Interface. Because this security is irrelevant to the context of this demo, I will first configure inbound endpoint just with https transport and no particular additional security. That gives me a chance to test everything right from the browser:

Sentinet gives me end-to-end monitoring of request/responses from the application (browser in this case) via Sentinet to Logic App.

You can also inspect each leg of this communication through the detailed Logs.

Aggregating multiple Logic Apps in a single RESTful API

Now I want to show how you can use Sentinet API Management to expose multiple Logic Apps through a single virtual API hosted by a Sentinet Node (API Gateway). The process is quite the same as described above.

This time to diversify the sample I will use another simple Logic App, called FullName, which is configured with HTTP POST URL and Request Body JSON Schema as shown below. Note, that this Logic App will get its own HTTP POST URL with its own Shared Access Signature in a sig query parameter.

I can register this physical API in the Sentinet as Full Name API with BuildFullName POST operation.

I can now use drag-and-drop again to add the Full Name physical service to the VHello virtual service, which automatically becomes an aggregate of two physical APIs (Logic Apps).

While mapping request of the virtual BuildFullName operation to its physical operation I again remove (hide) all query parameters from the virtualization:

the VHello API is an aggregate API with a single endpoint and two operations differentiated by relative paths:

Monitoring logs of the virtual API show how its operations (effectively Logic Apps) are called:

Customized Dashboards are automatically populated with the vital statistics of Logic Apps’ usage:

Securing Logic Apps

As I mentioned above, out-of-the-box Logic Apps come with their own non-standard Shared Access Signature security. They can also be secured with OAuth of Azure Active Directory. Using Sentinet API Management you can expose Logic Apps using any security and with no limitations by adding desired security to the inbound endpoints of the virtual services hosted in the Sentinet Node (API Gateway). This can be done in a matter of seconds by applying desired security Policy and Access Control. For example, I can apply mutual certificates security policy and a list of allowed client certificates for access control:

For an example of how to configure Sentinet with OAuth/Open ID Connect see another blog article here.