Adding an API key to an Azure Function Proxy using Logic Apps

Posted: November 28, 2018  |  Categories: Azure Function Logic Apps
Tags:

In the last project I’ve been working on, I got a requirement from a client where he wanted to consume an API exposed from Logic Apps with the security of an API key only. 

The Logic App HTTP Connector

This is easily achievable out-of-the-box in Logic Apps by using the access key appended in the URL of a Logic Apps that is using the Request-Response HTTP connector as below.

The URL generated by this connector is the following:

https://prod-02.australiasoutheast.logic.azure.com:443/workflows/workflow-id/triggers/request/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2Frequest%2Frun&sv=1.0&sig=access_key.

This access_key query parameter is the value that works as an API key to access this Logic App.

So, we can just expose this URL to our clients and they will be able to consume the Logic Apps with this layer of security. But the URL contains a lot of query string parameters that make the URL hard to read. It also contains a lot of unnecessary information that the client that is consuming the API does not need to know. And lastly, by reading the API, we don’t know what it will be returning to us as normal REST APIs does with URL like https://server/api/Entity (GET, POST, PUT, DELETE).

The Azure Function Proxy

So, the way we can improve the exposing of this URL to the client is by using some kind of API proxy and for that, I used the Azure Function Proxy.

To do that, I created some proxies in an Azure Function App with the following configuration:

As you can see above I have now a better Proxy URL (https://server/api/Customer) with a better naming convention using the api suffix and the name of the entity we are going to manipulate as good REST APIs. And all the parameters that I need to be passed like the access key, I’m using the Request override feature of Function Proxy.

I’m expecting in the header of this request a key-pair with the name of api-key (request.header.api-key). This value will be appended as the sig query parameter in the Backend URL, to complete the URL that Logic Apps need.

The catch here is that by receiving the access key in the header key-pair api-key, I’m making the Azure Function Proxy to behave as having authentication and authorization also while this actually belongs to the Logic app. (Azure Function Proxy does not have yet an API key functionality, as the the coded functions have)

Controlling keys and improving security

Once the access-key value is shared with the client, we can control when a new value of this key should be generated by going to the Access keys configuration in the Logic App and generating new values for Primary and Secondary keys as the picture below shows:

We can also improve even further the security of this Logic App, by just accepting requests from this particular Azure Function App, by getting its outbound IPs and adding to the list of IP ranges accepted to call the HTTP trigger:

Summary

In this post I showed a easy way to have api-key type of authentication using Azure Function Proxy with Logic Apps.

Please be aware that new changes and improvements are being made today for API Management that has better capabilities than Azure Functions Proxies and as soon they are released I’ll be posting about it here also.

See you around!!!

Author: Alessandro Moura

Certified BizTalk, Mulesoft, TOGAF and Azure. Integration Specialist. Solutions Architect.

Leave a Reply

turbo360

Back to Top