Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into swa/byo-afd

Author: craigshoemaker

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).

articles/static-web-apps/TOC.yml

@@ -75,6 +75,8 @@
     - name: Enable monitoring
       href: monitor.md
       displayName: Application Insights
+    - name: Enable enterprise-grade edge
+      href: enterprise-edge.md
     - name: Reset deployment tokens
       href: deployment-token-management.md
     - name: Troubleshoot errors

articles/static-web-apps/authentication-custom.md

@@ -302,19 +302,20 @@ If you are using Azure Active Directory, use `aad` as the value for the `<PROVID
 > [!Note]
 > These URLs are provided by Azure Static Web Apps to receive the response from the authentication provider, you don't need to create pages at these routes.
 
-## Login, logout, and purging user details
+## Login, logout, and user details
 
 To use a custom identity provider, use the following URL patterns.
 
 | Action             | Pattern                                  |
 | ------------------ | ---------------------------------------- |
 | Login              | `/.auth/login/<PROVIDER_NAME_IN_CONFIG>` |
 | Logout             | `/.auth/logout`                          |
+| User details       | `/.auth/me`                              |
 | Purge user details | `/.auth/purge/<PROVIDER_NAME_IN_CONFIG>` |
 
 If you are using Azure Active Directory, use `aad` as the value for the `<PROVIDER_NAME_IN_CONFIG>` placeholder.
 
 ## Next steps
 
 > [!div class="nextstepaction"]
-> [Securing authentication secrets in Azure Key Vault](./key-vault-secrets.md)
+> [Set user roles programmatically](./assign-roles-microsoft-graph.md)

articles/static-web-apps/enterprise-edge.md

@@ -0,0 +1,93 @@
+---
+title: Enterprise-grade edge (preview) in Azure Static Web Apps
+description: Learn about Azure Static Web Apps enterprise-grade edge (Preview)
+services: static-web-apps
+author: craigshoemaker
+ms.service: static-web-apps
+ms.topic: how-to
+ms.date: 01/11/2021
+ms.author: cshoe
+---
+
+# Enterprise-grade edge (Preview)
+
+Use Azure Static Web Apps enterprise-grade edge (Preview) to enable faster page loads, enhance security, and optimize reliability for your global applications. Enterprise edge combines the capabilities of Azure Static Web Apps, Azure Front Door, and Azure Content Delivery Network (CDN) into a single secure cloud CDN platform.
+
+Key features of Azure Static Web Apps enterprise-grade edge include:
+
+* Global presence in 118+ [edge locations](/azure/frontdoor/edge-locations-by-region) across 100 metro cities.
+
+* Caching assets at the [edge](/azure/frontdoor/front-door-caching).
+
+* Proactive protection against [Distributed Denial of Service (DDoS) attacks](/azure/frontdoor/front-door-ddos).
+
+* Native support of end-to-end IPv6 connectivity and [HTTP/2 protocol](/azure/frontdoor/front-door-http2.md).
+
+* Optimized file compression.
+
+> [!NOTE]
+> Static Web Apps enterprise-grade edge is currently in preview.
+
+## Caching
+
+When enterprise-grade edge is enabled for your static web app, you benefit from caching at various levels.
+
+* **CDN**: Caching content on edge locations as physically close to users a possible to reduce latency.
+
+* **DNS**: Caching DNS records for faster lookups.
+
+* **Browser**: Files are stored in the browser and returned for identical requests.
+
+For further control, you can also create [custom cache control headers](configuration.md) for your static web app.
+
+## Configuration types
+
+You can enable enterprise-grade edge powered by Azure Front Door via a managed experience through the Azure portal, or you [can set it up manually](front-door-manual.md).
+
+A managed experience provides:
+
+* Zero configuration changes
+* No downtime
+* Automatically managed SSL certifications and custom domains
+
+A manual setup gives you full control over the CDN configuration including the chance to:
+
+* Limit traffic origin by origin
+* Add a web application firewall
+* Use more advanced features of Azure Front Door
+
+## Enable enterprise-grade edge
+
+### Prerequisites
+
+* [Custom domain](./custom-domain.md) configured for your static web app with a time to live (TTL) set to less than 48 hrs.
+* An application deployed with [Azure Static Web Apps](./get-started-portal.md) that uses the Standard hosting plan.
+
+# [Azure portal](#tab/azure-portal)
+
+1. Navigate to your static web app in the Azure portal.
+
+1. Select **Enterprise-grade edge** in the left menu.
+
+1. Check the box labeled **Enable enterprise-grade edge**.
+
+1. Select **Save**.
+
+1. Select **OK** to confirm the save.
+
+    Enabling this feature incurs extra costs.
+
+# [Azure CLI](#tab/azure-cli)
+
+```azurecli
+az extension add -n enterprise-edge
+
+az staticwebapp enterprise-edge enable -n my-static-webapp -g my-resource-group
+```
+
+---
+
+## Next steps
+
+> [!div class="nextstepaction"]
+> [Application configuration](configuration.md)