Merge pull request #182904 from jelledruyts/jelledruyts/msi-tokencache

Add FAQ and notes on token caching

Author: ShannonLeavitt

articles/active-directory/managed-identities-azure-resources/how-to-assign-app-role-managed-identity-cli.md

@@ -22,6 +22,9 @@ ms.custom: devx-track-azurepowershell
 
 Managed identities for Azure resources provide Azure services with an identity in Azure Active Directory. They work without needing credentials in your code. Azure services use this identity to authenticate to services that support Azure AD authentication. Application roles provide a form of role-based access control, and allow a service to implement authorization rules.
 
+> [!NOTE]
+> The tokens which your application receives are cached by the underlying infrastructure, which means that any changes to the managed identity's roles can take significant time to take effect. For more information, see [Limitation of using managed identities for authorization](managed-identity-best-practice-recommendations.md#limitation-of-using-managed-identities-for-authorization).
+
 In this article, you learn how to assign a managed identity to an application role exposed by another application using Azure CLI.
 
 ## Prerequisites

articles/active-directory/managed-identities-azure-resources/how-to-assign-app-role-managed-identity-powershell.md

@@ -22,6 +22,9 @@ ms.custom: devx-track-azurepowershell
 
 Managed identities for Azure resources provide Azure services with an identity in Azure Active Directory. They work without needing credentials in your code. Azure services use this identity to authenticate to services that support Azure AD authentication. Application roles provide a form of role-based access control, and allow a service to implement authorization rules.
 
+> [!NOTE]
+> The tokens which your application receives are cached by the underlying infrastructure, which means that any changes to the managed identity's roles can take significant time to take effect. For more information, see [Limitation of using managed identities for authorization](managed-identity-best-practice-recommendations.md#limitation-of-using-managed-identities-for-authorization).
+
 In this article, you learn how to assign a managed identity to an application role exposed by another application using Azure AD PowerShell.
 
 [!INCLUDE [az-powershell-update](../../../includes/updated-for-az.md)]

articles/active-directory/managed-identities-azure-resources/managed-identities-faq.md

@@ -101,7 +101,7 @@ Managed identities use certificate-based authentication. Each managed identity
 
 ### What identity will IMDS default to if don't specify the identity in the request?
 
-- If system assigned managed identity is enabled and no identity is specified in the request, IMDS defaults to the system assigned managed identity.
+- If system assigned managed identity is enabled and no identity is specified in the request, Azure Instance Metadata Service (IMDS) defaults to the system assigned managed identity.
 - If system assigned managed identity is not enabled, and only one user assigned managed identity exists, IMDS defaults to that single user assigned managed identity.
 - If system assigned managed identity is not enabled, and multiple user assigned managed identities exist, then you are required to specify a managed identity in the request.
 
@@ -143,6 +143,10 @@ Managed identities limits have dependencies on Azure service limits, Azure Insta
 
 Moving a user-assigned managed identity to a different resource group is not supported.
 
+### Are tokens cached after they are issued for a managed identity?
+
+Managed identity tokens are cached by the underlying Azure infrastructure for performance and resiliency purposes: 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 permissions to take effect, for example. Today, it is not possible to force a managed identity's token to be refreshed before its expiry. For more information, see [Limitation of using managed identities for authorization](managed-identity-best-practice-recommendations.md#limitation-of-using-managed-identities-for-authorization).
+
 ## Next steps
 
 - Learn [how managed identities work with virtual machines](how-managed-identities-work-vm.md)

articles/active-directory/managed-identities-azure-resources/managed-identity-best-practice-recommendations.md

@@ -106,10 +106,12 @@ will be displayed with “Identity not found” when viewed in the portal. [Read
 
 :::image type="content" source="media/managed-identity-best-practice-recommendations/identity-not-found.png" alt-text="Identity not found for role assignment.":::
 
-## Limitation of using Azure AD Groups with managed identities for authorization
+## Limitation of using managed identities for authorization
 
-Using Azure AD Groups for granting access to services is a great way to simplify the authorization process. The idea is simple – grant permissions to a group and add identities to the group so that they inherit the same permissions. This is a well-established pattern from various on-premises systems and works well when the identities represent users. However, for non-human identities, such as Azure AD Applications and Managed identities, the exact mechanism is not well suited today. Today’s implementation with Azure AD and Azure Role Based Access Control (Azure RBAC), uses access tokens issued by Azure AD for authentication of each identity. However, if the identity is added to a group, its group membership is expressed as a claim in the access token issued by Azure AD. Azure RBAC uses this claim to further evaluate the authorization rules for allowing or denying access.  
+Using Azure AD **groups** for granting access to services is a great way to simplify the authorization process. The idea is simple – grant permissions to a group and add identities to the group so that they inherit the same permissions. This is a well-established pattern from various on-premises systems and works well when the identities represent users. Another option to control authorization in Azure AD is by using [App Roles](../develop/howto-add-app-roles-in-azure-ad-apps.md), which allows you to declare **roles** that are specific to an app (rather than groups, which are a global concept in the directory). You can then [assign app roles to managed identities](how-to-assign-app-role-managed-identity-powershell.md) (as well as users or groups).
 
-As the group membership is a claim in the access token, group membership changes do not take effect until the token is refreshed. A human user can acquire a new access token by logging out and in again. Managed identity tokens are cached by the underlying Azure infrastructure for performance and resiliency purposes. This means that it can take several hours for changes to a managed identity’s group 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 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, compared to just a few minutes if you were to add or remove permissions directly on the identity.
+In both cases, for non-human identities such as Azure AD Applications and Managed identities, the exact mechanism of how this authorization information is presented to the application is not ideally suited today. Today's implementation with Azure AD and Azure Role Based Access Control (Azure RBAC) uses access tokens issued by Azure AD for authentication of each identity. If the identity is added to a group or role, this is expressed as claims in the access token issued by Azure AD. Azure RBAC uses these claims to further evaluate the authorization rules for allowing or denying access.
 
-To ensure that changes to permissions for managed identities take effect quickly, we recommend that you group Azure resources using a [user-assigned managed identity](how-manage-user-assigned-managed-identities.md?pivots=identity-mi-methods-azcli) with permissions applied directly to the identity, instead of adding to or removing managed identities from an Azure AD group that has permissions. A user-assigned managed identity can be used like a group because it can be assigned to one or more Azure resources to use it. The assignment operation can be controlled using the [Managed identity contributor](../../role-based-access-control/built-in-roles.md#managed-identity-contributor) and [Managed identity operator role](../../role-based-access-control/built-in-roles.md#managed-identity-operator).
+Given that the identity's groups and roles are claims in the access token, any authorization changes do not take effect until the token is refreshed. For a human user that's typically not a problem, because a user can acquire a new access token by logging out and in again (or waiting for the token lifetime to expire, which is 1 hour by default). Managed identity tokens on the other hand are cached by the underlying Azure infrastructure for performance and resiliency purposes: 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.
+
+If this delay is not acceptable for your requirements, consider alternatives to using groups or roles in the token. To ensure that changes to permissions for managed identities take effect quickly, we recommend that you group Azure resources using a [user-assigned managed identity](how-manage-user-assigned-managed-identities.md?pivots=identity-mi-methods-azcli) with permissions applied directly to the identity, instead of adding to or removing managed identities from an Azure AD group that has permissions. A user-assigned managed identity can be used like a group because it can be assigned to one or more Azure resources to use it. The assignment operation can be controlled using the [Managed identity contributor](../../role-based-access-control/built-in-roles.md#managed-identity-contributor) and [Managed identity operator role](../../role-based-access-control/built-in-roles.md#managed-identity-operator).