DataProtection and scaling /8

aspnetcore/host-and-deploy/web-farm.md

@@ -38,11 +38,17 @@ When an app is scaled to multiple instances, there might be app state that requi
 
 ## Required configuration
 
-Data Protection and Caching require configuration for apps deployed to a web farm.
+Data Protection and Caching may require configuration for apps deployed to a web farm.
 
-### Data Protection
+### Data Protection in distributed environments
 
-The [ASP.NET Core Data Protection system](xref:security/data-protection/introduction) is used by apps to protect data. Data Protection relies upon a set of cryptographic keys stored in a *key ring*. When the Data Protection system is initialized, it applies [default settings](xref:security/data-protection/configuration/default-settings) that store the key ring locally. Under the default configuration, a unique key ring is stored on each node of the web farm. Consequently, each web farm node can't decrypt data that's encrypted by an app on any other node. The default configuration isn't generally appropriate for hosting apps in a web farm. An alternative to implementing a shared key ring is to always route user requests to the same node. For more information on Data Protection system configuration for web farm deployments, see <xref:security/data-protection/configuration/overview>.
+The [ASP.NET Core Data Protection system](xref:security/data-protection/introduction) is used by apps to protect data. Data Protection relies upon a set of cryptographic keys stored in a *key ring*. When the Data Protection system is initialized, it applies [default settings](xref:security/data-protection/configuration/default-settings) that store the key ring locally. The default configuration is appropriate for apps that run in a single instance.
+
+Apps that are running in distributed environments that don't configure Data Protection automatically need to explicitly configure Data Protection. See <xref:security/data-protection/configuration/scaling> for environments that require explicit Data Protection configuration and those that don't.
+
+Under the default configuration, a unique key ring is stored on each node of the web farm. Consequently, each web farm node can't decrypt data that's encrypted by an app on any other node. The default configuration isn't generally appropriate for hosting apps in a web farm. Sticky sessions using [ARR Affinity](/azure/app-service/manage-automatic-scaling?#how-does-arr-affinity-affect-automatic-scaling) is an alternative to implementing a shared key ring is to always route user requests to the same node. However, ARR can reduce the scalability of a web farm.
+
+For more information on Data Protection system configuration for web farm deployments, see <xref:security/data-protection/configuration/overview>.
 
 ### Caching
 

aspnetcore/security/data-protection/configuration/default-settings.md

@@ -14,7 +14,7 @@ By [Rick Anderson](https://twitter.com/RickAndMSFT)
 
 The app attempts to detect its operational environment and handle key configuration on its own.
 
-1. If the app is hosted in [Azure Apps](https://azure.microsoft.com/services/app-service/), keys are persisted to the *%HOME%\ASP.NET\DataProtection-Keys* folder. This folder is backed by network storage and is synchronized across all machines hosting the app.
+1. If the app is hosted in [Azure Apps](/azure/app-service/overview), keys are persisted to the *%HOME%\ASP.NET\DataProtection-Keys* folder. This folder is backed by network storage and is synchronized across all machines hosting the app.
    * Keys aren't protected at rest.
    * The *DataProtection-Keys* folder supplies the key ring to all instances of an app in a single deployment slot.
    * Separate deployment slots, such as Staging and Production, don't share a key ring. When you swap between deployment slots, for example swapping Staging to Production or using A/B testing, any app using Data Protection won't be able to decrypt stored data using the key ring inside the previous slot. This leads to users being logged out of an app that uses the standard ASP.NET Core cookie authentication, as it uses Data Protection to protect its cookies. If you desire slot-independent key rings, use an external key ring provider, such as Azure Blob Storage, Azure Key Vault, a SQL store, or Redis cache.

aspnetcore/security/data-protection/configuration/scaling.md

@@ -0,0 +1,36 @@
+---
+title: Configure ASP.NET Core Data Protection in distributed or load-balanced environments
+author: acasey
+description: Learn how to configure Data Protection in ASP.NET Core for multi-instance apps.
+ms.author: acasey
+ms.date: 7/18/2024
+content_well_notification: AI-contribution
+ms.prod: aspnet-core
+uid: security/data-protection/configuration/scaling
+---
+
+# Configure ASP.NET Core Data Protection in distributed or load-balanced environments
+
+:::moniker range=">= aspnetcore-8.0"
+
+ASP.NET Core [Data Protection](xref:security/data-protection/introduction) is a library that provides a cryptographic API to protect data. Data Protection protects anti-forgery tokens, authentication cookies, and other sensitive data. However, in some distributed environments that don't put data protection keys in shared storage, when an app scales horizontally by adding more instances:
+
+* It's necessary to explicitly configure Data Protection to establish a shared storage location for Data Protection keys.
+* There’s ***NO*** guarantee that the HTTP POST request, used to submit a form, will be routed to the same instance that served the initial page via an HTTP GET request. If the requests are handled by different instances, the anti-forgery tokens aren’t synchronized, and an exception occurs. Sticky sessions via [ARR Affinity](/azure/app-service/manage-automatic-scaling?#how-does-arr-affinity-affect-automatic-scaling) routes user requests to the same node. However, ARR can reduce the scalability of a web farm.
+
+The following distributed environments provide automatic key storage in a shared location:
+
+* [Azure apps](/aspnet/core/security/data-protection/configuration/default-settings).  For more information see <xref:security/data-protection/configuration/default-settings#key-management>.
+* Newly created Azure Container Apps built using ASP.NET Core. For more information see [Autoscaling considerations
+](/azure/container-apps/dotnet-overview#autoscaling-considerations).
+
+The following scenarios do ***NOT*** provide automatic key storage in a shared location:
+
+* Separate [deployment slots](/azure/app-service/deploy-staging-slots), such as Staging and Production.
+* Azure Container Apps built using ASP.NET Core Kestrel 7.0 or earlier. For more information see [Autoscaling considerations
+](/azure/container-apps/dotnet-overview#autoscaling-considerations).
+* Asp.net core apps hosted on multiple non-Azure VMs that don't use server affinity. Server affinity ensures that a client's requests are always routed to the same server so having the keys in a shared location is not necessary. For more information see [Server affinity](/azure/app-service/manage-automatic-scaling?#how-does-arr-affinity-affect-automatic-scaling).
+
+:::moniker-end
+
+[!INCLUDE[](~/security/data-protection/configuration/scaling/includes/scaling7.md)]

aspnetcore/security/data-protection/configuration/scaling/includes/scaling7.md

@@ -0,0 +1,9 @@
+
+:::moniker range="< aspnetcore-8.0"
+
+<!--
+Duplicate of primary doc, only change:
+using .NET 8.0
+ -->
+
+:::moniker-end