How Many Ways to Secure your Azure API Management Infrastructure?

You are a financial technology company (fintech) and you are considering provisioning Azure API Management (APIM) as part of your EU PSD2 and UK Open Banking strategy for public facing Web APIs. Security is at the top of your agenda and you need to know what mechanisms are available to secure APIM and your Web APIs?

You may choose to implement some or all of these security options:

1, Ocp-Apim-Subscription-KeyAt a fundamental level, every request made to an APIM operation must include an Ocp-Apim-Subscription-Key in the Authorisation request header. This is assuming that the Product it is linked to is configured as protected and requires a subscription. The key identifies the developer APIM subscription and can be found and managed in the Developer Portal. As best practice, it should be regenerated as part of a password rotation policy.

2, Secure your Back End API using OAuth2/JWT

This is where the back end Web API can be secured using an Authorisation Server (AS) such as Azure Active Directory, such that each client application request header must contain a valid OAuth2 JWT token – otherwise a 401 Unauthorized will be returned.

The Web client must first obtain an expiring JWT access token from the AS. This can be achieved in two ways. The first way is by supplying a clientID (Aka: ApplicationID) and Secret in the token request. The second way is to supply a username/password combination. Both requests must be executed over HTTPS.

Note: the APIM Developer Portal supports OAuth2/JWT, whereby an Authorisation Server must be configured in the APIM to provide the JWT token to the back end API.

If your back end API implements OAuth2, then you can additionally implement an APIM policy expression which requires that a JWT token be supplied by the client application in the request header. JWT validation policy expressions can actually be very granular. Eg: a policy expressions can check that a client application http post request header includes a particular JWT token containing a matching claim

3, Client Certificate

An additional APIM policy can be configured comparing an incoming client certificate against a certificate uploaded to APIM. It works as follows: Within the APIM policy a context object is available that gives access to both incoming certificates and any certificates stored in APIM. Hence the C# code below within the policy compares thumbprints of incoming and APIM stored certificates:
<when condition="@(context.Request.Certificate == null || !context.Deployment.Certificates.Any(c =>              c.Value.Thumbprint == context.Request.Certificate.Thumbprint))" >
<set-status code="403" reason="Invalid client certificate" />
</return-response> </when>

One final point. We can now check for an incoming certificate but how does the client developer include a certificate in a client request? Answer: Install a certificate on the client machine and load it up in the request from code. For a great article to do this click here.

4, APIM to Back End API Mutual Certification

A mechanism called TLS mutual authentication or client certificate authentication can be setup for Azure based Web Apps or API Apps. This does not work over HTTP but requires HTTPS. Hence a certificate must be installed on both the Web App and APIM. The Web App requires the “clientCertEnabled” setting to be set to true. Unfortunately this setting requires a call via the Azure REST API as is not yet available in the portal. The validation of the incoming certificate can currently only be done through code in the Web App. In ASP.NET the incoming certificate is extracted from the header using var c =headers[“X-ARR-ClientCert”].

5, IP Address White-list the APIM in Azure BEAPI
As the APIM has a static IP Address, the Azure BEAPI can white-list only the APIM. Hence, the  Azure BEAPI will reject all calls except those from the APIM IP address.

6, IP Address White-list the client in APIM by policy
Configuring a VNET for APIM to access on premise BEAP
Using a VNET avoids having to expose an on premise BEAPI to the public internet.

7, Configuring APIM RBAC
You can control which users in your organisation have access to APIM and what they can do.

8, Users/Groups/Products
A published product grants visibility to Groups. A User must be a member of a Group. Users and Groups can be created manually or may originate from a local AAD or partner AAD.

9, Access to Developer Portal from Identity Providers
Access to the Developer Portal can be granted to users via a selection of identity providers. This can include accounts in local or partner Azure AD or social media accounts.

10, HttpsAll traffic should be encrypted in transit using HTTPS. This requires a certificate at each Application node.

11, Policy

Configuring multiple products across APIs to enforce individual rates, quotas, custom security through APIM policy.

12, Logging all requests that reach APIM into Azure Event Hub.
APIM does provide a fully comprehensive audit of all requests that are received but only a subset. If full audit, or miscellaneous trace details are required then APIM can be configured to forward these details to a logger. For performance reasons the logger typically publishes to an Azure Event Hub. Subscribers of the Event Hub can be setup. These could include technologies such as: Azure Table Storage, Stream Analytics, PowerBI and Azure Machine Learning.


Leave a Reply

Your email address will not be published. Required fields are marked *