Use Azure API Management Credential Manager to access Azure resources... such as Blob storage
The original post (Japanese) was written on 30 April 2024.
Query
One of my blog readers asked me about the following topic.
I am now considering using API Management (APIM) to create wrapper APIs of Blob Storage REST APIs. Having read your previous posts, I have a good understanding of how to use managed identities on APIM, but is it possible to use Credentials Manager as well? What are the benefits of using Credentials Manager?
“Previous posts” means the following (sorry, all are in Japanese).
My assumptions were listed below, but I decided to verify them.
- It is possible and basically the same.
- But there are some limitations in Managed Identities.
Credential Manager
As mentioned in the previous entry, it obtains and updates tokens for back-end services that require authorization with OAuth 2.0.
We can configure either authorization code grant flow or client credentials grant flow in Credential Manager.
In this post, I am using Put Blob API for description. More details about the API can be found at the following URL.
The configuration steps are almost the same as in the following tutorial, except for the parts specific to the Graph API. I have added some steps specific to blob storage as a reminder.
1. Steps in Microsoft Entra ID
i) Register applications
Even when using either authorization code grant flow or client credentials grant flow, application registration to Microsoft Entra ID is needed. Once registration is complete, ClientId is generated.
ii) Create secrets
Once you’ve registered your application, you can create a secret. The secret won’t be visible forever, so make a note of it.
iii) Configure API Permissions
Add permissions to your application. In this case, add the user_impersonation permission of the Storage API.
This permission does not require administrator approval, as you see the message in Azure Portal below.
This completes the configuration in Microsoft Entra ID.
2. Steps in Blob storage
Obviously, we need to create a storage account and a blob container. Once the blob container is created, we configure RBAC for the blob container. In this case, we assign “Storage Blob Data Contributor” role to principals. Note that the principals to be granted are different depending upon grant flow.
- Authorization code: registered application and users who have delegated operations to the application
- Client credentials: registered application
The blob storage container configuration is complete.
3. Steps in APIM
a) Configuration in Credential Manager
Create credential provider and connection in credential manager. Navigate to APIs > Credential manager and click “Create”.
Please note the following points when filling in the form.
Tenant ID
- If you’re using multiple Entra ID tenants, we recommend that you explicitly specify one tenant ID that represents the Microsoft Entra ID tenant that manages the Azure subscription.
Authorization URL
- The URL
https://login.microsoftonline.comusually works.
Resource URL
- In this case, we need to specify the Blob storage endpoint
https://<storage-account-name>.blob.core.windows.net/instead of the FQDN with the blob containerhttps://<storage-account-name>.blob.core.windows.net/<container-name>.
Scopes
If you have already configured scopes (API Permissions) in Microsoft Entra ID, you don’t need to specify them as the wizard will retrieve them automatically.
Once you confirm that the connection is working, the configuration in the Credential Manager is complete.
b) Creating APIs
If we need to call backend APIs with authorization header, we need to get access tokens from the credential manager. As I mentioned in the previous entry, please note that “Provider ID” stands for credential provider name and “Authorization ID” stands for connection name.
<policies>
<inbound>
<base />
<get-authorization-context provider-id="{credential provider name}"
authorization-id="{connection name}"
context-variable-name="auth-context"
identity-type="managed"
ignore-error="false" />
<set-header name="Authorization" exists-action="override">
<value>@("Bearer " + ((Authorization)context.Variables.GetValueOrDefault("auth-context"))?.AccessToken)</value>
</set-header>
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>Note that we need to configure the HTTP headers required by the Put blob REST API, such as x-ms-version, x-ms-blob-type, etc. As this configuration is needed in both flows, we can configure this in the All Operations scope.
<policies>
<inbound>
<base />
<set-header name="x-ms-version" exists-action="override">
<value>2024-05-04</value>
</set-header>
<set-header name="x-ms-blob-type" exists-action="override">
<value>BlockBlob</value>
</set-header>
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>That’s it. Time for a test!
Let’s try!
In the case of authorization code grant flow, users are asked to agree to delegated operations (user impersonation) unless administrators have already agreed. Access tokens contain delegated user information.
In the case of client credentials grant flow, on the other hand, access tokens do not contain any information about delegated users because there is no delegated operation (ClientId of the registered application is stored in appId attribute of the JWT).
When and where should we use each flow?
Client credentials grant flow
This flow is mainly used for backend services with no user interaction. If we don’t need to track users who delegated the operation, this flow is suitable.
Authorization code grant flow
This grant flow is mainly used for user delegation and this type of API is used with web applications. If the user who delegated the operation can be found, it can be used to trace who performed the operation.
Can we do the same thing with APIM’s Managed Identity as with Credential Manager?
Yes, but there are some limitations. First of all, Managed Identities are principals and they work the same way as registered applications in Microsoft Entra ID.
We can use Managed Identities for authentication/authorization against Azure REST APIs, just like with Credential Manager. In fact, Managed Identities allows us to configure the APIs backed by Azure REST APIs more easily than with credential manager, but we should keep in our mind the following points.
The scope of Managed Identities is within Azure.
Indeed, we can use Credential Manager for Azure resources as well as Microsoft 365 APIs and the 3rd party APIs. However, Managed Identities only works with Azure resources only.
Is it good that lots of privileges are granted to the single Managed Identity of APIM?
From security point of view, we should keep the least privilege principle of each identity, and this is also true for Managed Identities. So, it is a better way to configure other identities and delegate some privileges to them.
