How to use managed identities for App Service and Azure Functions
Članak
Napomena
Starting June 1, 2024, newly created App Service apps can generate a unique default hostname that uses the naming convention <app-name>-<random-hash>.<region>.azurewebsites.net. Existing app names remain unchanged. For example:
A managed identity from Microsoft Entra ID allows your app to easily access other Microsoft Entra protected resources such as Azure Key Vault. The identity is managed by the Azure platform and does not require you to provision or rotate any secrets. For more about managed identities in Microsoft Entra ID, see Managed identities for Azure resources.
Your application can be granted two types of identities:
A system-assigned identity is tied to the app and is deleted if the app is deleted. An app can only have one system-assigned identity.
A user-assigned identity is a standalone Azure resource that can be assigned to your app. An app can have multiple user-assigned identities, and one user-assigned identity can be assigned to multiple Azure resources, such as two App Service apps.
The managed identity configuration is specific to the slot. To configure a managed identity for a deployment slot in the portal, navigate to the slot first. To find the managed identity for your web app or deployment slot in your Microsoft Entra tenant from the Azure portal, search for it directly from the Overview page of your tenant. Usually, the slot name is similar to <app-name>/slots/<slot-name>.
This video shows you how to use managed identities for App Service.
The steps in the video are also described in the following sections.
Prerequisites
To perform the steps covered in this document, you must have a minimum set of permissions over your Azure resources. The specific permissions set you need will vary based on your scenario. The most common scenarios are summarized in the following table:
Microsoft.Web/sites/write over the app (or Microsoft.Web/sites/slots/write over the slot), Microsoft.ManagedIdentity/userAssignedIdentities/*/assign/action over the identity
A different set of permissions might be needed for other scenarios.
Add a system-assigned identity
To enable a system-assigned managed identity on your app or slot, you need write permissions over that app or slot. The Website Contributor role provides these permissions.
The tenantId property identifies what Microsoft Entra tenant the identity belongs to. The principalId is a unique identifier for the application's new identity. Within Microsoft Entra ID, the service principal has the same name that you gave to your App Service or Azure Functions instance.
If you need to reference these properties in a later stage in the template, you can do so via the reference() template function with the 'Full' flag, as in this example:
Creating an app with a user-assigned identity requires that you create the identity and then add its resource identifier to your app config.
To assign a user-assigned managed identity to your app or slot, you need write permissions over that app or slot. The Website Contributor role provides these permissions. You must also have permission to assign the user-assigned managed identity you will be using. The Managed Identity Operator role provides these permissions.
Any resource of type Microsoft.Web/sites can be created with an identity by including the following block in the resource definition, replacing <resource-id> with the resource ID of the desired identity:
An application can have both system-assigned and user-assigned identities at the same time. In this case, the type property would be SystemAssigned,UserAssigned
Adding the user-assigned type tells Azure to use the user-assigned identity specified for your application.
For example, a web app's template might look like the following JSON:
The principalId is a unique identifier for the identity that's used for Microsoft Entra administration. The clientId is a unique identifier for the application's new identity that's used for specifying which identity to use during runtime calls.
Configure target resource
You need to configure the target resource to allow access from your app. For most Azure services, you do this by creating a role assignment. Some services use mechanisms other than Azure RBAC. Refer to the documentation for each target resource to understand how to configure access using an identity. To learn more about which resources support Microsoft Entra tokens, see Azure services that support Microsoft Entra authentication.
For example, if you request a token to access a secret in Key Vault, you must also create a role assignment that allows the managed identity to work with secrets in the target vault. Otherwise, your calls to Key Vault will be rejected, even if you use a valid token. The same is true for Azure SQL Database and other services.
Važno
The back-end services for managed identities maintain a cache per resource URI for around 24 hours. This means that it can take several hours for changes to a managed identity's group or role membership to take effect. Today, it is not possible to force a managed identity's token to be refreshed before its expiry. If you change a managed identity’s group or role membership to add or remove permissions, you may therefore need to wait several hours for the Azure resource using the identity to have the correct access. For alternatives to groups or role memberships, see Limitation of using managed identities for authorization.
Connect to Azure services in app code
With its managed identity, an app can obtain tokens for Azure resources that are protected by Microsoft Entra ID, such as Azure SQL Database, Azure Key Vault, and Azure Storage. These tokens represent the application accessing the resource, and not any specific user of the application.
App Service and Azure Functions provide an internally accessible REST endpoint for token retrieval. The REST endpoint can be accessed from within the app with a standard HTTP GET, which can be implemented with a generic HTTP client in every language. For .NET, JavaScript, Java, and Python, the Azure Identity client library provides an abstraction over this REST endpoint and simplifies the development experience. Connecting to other Azure services is as simple as adding a credential object to the service-specific client.
The linked examples use DefaultAzureCredential. It's useful for the majority of the scenarios because the same pattern works in Azure (with managed identities) and on your local machine (without managed identities).
The linked examples use DefaultAzureCredential. It's useful for the majority of the scenarios because the same pattern works in Azure (with managed identities) and on your local machine (without managed identities).
For more code examples of the Azure Identity client library for JavaScript, see Azure Identity examples.
The linked examples use DefaultAzureCredential. It's useful for the majority of the scenarios because the same pattern works in Azure (with managed identities) and on your local machine (without managed identities).
The linked examples use DefaultAzureCredential. It's useful for the majority of the scenarios because the same pattern works in Azure (with managed identities) and on your local machine (without managed identities).
For more code examples of the Azure Identity client library for Java, see Azure Identity Examples.
Use the following script to retrieve a token from the local endpoint by specifying a resource URI of an Azure service:
When you remove a system-assigned identity, it's deleted from Microsoft Entra ID. System-assigned identities are also automatically removed from Microsoft Entra ID when you delete the app resource itself.
To remove a managed identity from your app or slot, you need write permissions over that app or slot. The Website Contributor role provides these permissions.
To remove all identities in Azure PowerShell (Azure Functions only):
Azure PowerShell
# Update an existing function app to have IdentityType "None".Update-AzFunctionApp -Name$functionAppName -ResourceGroupName$resourceGroupName -IdentityType None
To remove all identities in an ARM template:
JSON
"identity": {
"type": "None"
}
Napomena
There is also an application setting that can be set, WEBSITE_DISABLE_MSI, which just disables the local token service. However, it leaves the identity in place, and tooling will still show the managed identity as "on" or "enabled." As a result, use of this setting is not recommended.
REST endpoint reference
An app with a managed identity makes this endpoint available by defining two environment variables:
IDENTITY_ENDPOINT - the URL to the local token service.
IDENTITY_HEADER - a header used to help mitigate server-side request forgery (SSRF) attacks. The value is rotated by the platform.
The IDENTITY_ENDPOINT is a local URL from which your app can request tokens. To get a token for a resource, make an HTTP GET request to this endpoint, including the following parameters:
The version of the token API to be used. Use 2019-08-01.
X-IDENTITY-HEADER
Header
The value of the IDENTITY_HEADER environment variable. This header is used to help mitigate server-side request forgery (SSRF) attacks.
client_id
Query
(Optional) The client ID of the user-assigned identity to be used. Cannot be used on a request that includes principal_id, mi_res_id, or object_id. If all ID parameters (client_id, principal_id, object_id, and mi_res_id) are omitted, the system-assigned identity is used.
principal_id
Query
(Optional) The principal ID of the user-assigned identity to be used. object_id is an alias that may be used instead. Cannot be used on a request that includes client_id, mi_res_id, or object_id. If all ID parameters (client_id, principal_id, object_id, and mi_res_id) are omitted, the system-assigned identity is used.
mi_res_id
Query
(Optional) The Azure resource ID of the user-assigned identity to be used. Cannot be used on a request that includes principal_id, client_id, or object_id. If all ID parameters (client_id, principal_id, object_id, and mi_res_id) are omitted, the system-assigned identity is used.
Važno
If you are attempting to obtain tokens for user-assigned identities, you must include one of the optional properties. Otherwise the token service will attempt to obtain a token for a system-assigned identity, which may or may not exist.
Pridružite se seriji susreta kako biste s kolegama programerima i stručnjacima izgradili skalabilna rješenja umjetne inteligencije temeljena na stvarnim slučajevima upotrebe.
Managed identity is one of unique functionalities in Azure and it allows us to authenticate callers and configure RBAC against called resources without storing caller credentials. We can see several examples to use managed identity in Azure documents, but the following questions might come to your mind. How do we configure authentication among Azure App Services/Functions with managed identity? Cannot we achieve such configuration? If we can, how do we implement App Service/Functions in Java to achieve thi
Learn how to set up Azure App Service and Azure Functions to use Azure Key Vault references. Make Key Vault secrets available to your application code.