One of the main reasons to introduce an API gateway is to establish uniform security controls on top of your API infrastructure. The focus is mostly on the frontdoor security. However, securing the last mile should also be high on your priority list. Thanks to recent integrations of Azure API Management with Azure Active Directory, there’s now the capability to secure that last mile without passwords, keys or certificates. Let’s have a look!
Managed Service Identity
The magic is performed by Managed Service Identity (MSI), which is a feature of Azure Active Directory (AAD). Instead of creating an explicit service principal, you can enable MSI on your Azure API Management instance. This gives a unique AAD identity to your APIM instance. You can use this identity to access Azure services that support AAD authentication, such as Blob Storage, SQL Database, Azure Resource Manager, etc… The great thing is that you don’t need to store a client id & secret, as everything is managed by the Azure runtime itself.
The MSI authentication policy
You can establish a passwordless backdoor security, by using the – recently added – Authenticate with managed identity policy.
<authentication-managed-identity resource="resource" output-token-variable-name="token-variable" ignore-error="true|false"/>
The documentation is quite clear on the usage of the policy. It’s important to understand that you should adapt the resource, depending on the service you need to authenticate to. Some common examples are:
- Azure Resource Manager: https://management.azure.com/
- Azure Key Vault: https://vault.azure.net
- Azure Service Bus: https://servicebus.azure.net/
- Azure Blob Storage: https://storage.azure.com/
- Azure SQL: https://database.windows.net/
In case you want to authenticate against a web API, you can also provide the App ID as the resource. This approach will be used in one of my follow-up posts.
Under the hood, APIM is requesting an OAuth2 access token, using the client credentials flow. This access token (JWT) is added as a Bearer token inside the authorization HTTP header. Pretty similar to this complex policy that had to be used in the past.
You can use this authentication policy for all backend services that support Azure AD authentication. A complete and up-to-date list of AAD-supported services can be found here. Some use cases that really benefited from this autentication policy are explained in more depth over here:
- Control your Azure Functions securely via Azure API Management (coming soon)
- Creating a serverless Azure Data Lake Gen2 connector (coming soon)
- Securely expose Azure Machine Learning web services (coming soon)
Very useful addition to our toolbox. I was surprised to see that there was not a lot of noise about this Managed Service Identity support. It’s really a hidden gem and extremely powerful. No more passwords to maintain, no more keys to rotate, no more certificates that might expire…