DataProtection and scaling /8

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

@@ -38,11 +38,11 @@ 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
 
-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. For more information, see <xref:security/data-protection/configuration/scaling>.
 
 ### 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.custom: mvc
+ms.date: 7/15/2024
+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 utilize 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 antiforgery tokens aren’t synchronized, and an exception occurs.
+
+The following distributed environments provide automatic key storage in a shared location:
+
+* [Azure apps](/aspnet/core/security/data-protection/configuration/default-settings).
+* Newly created <!-- what does newly created mean? --> Azure Container Apps built using ASP.NET Core Kestrel <!-- 8.0 and later We don't like to have version information in an article when it's not needed. Given the moniker for this content is 8.0+, we'd normally leave out that redundant info. However, we make exceptions. I can leave 8.0 in if you think it's helpful -->. For more information see [Autoscaling considerations
+](/azure/container-apps/dotnet-overview#autoscaling-considerations).
+* Azure Apps. For more information see <xref:security/data-protection/configuration/default-settings#key-management>.
+
+The following distributed environments do ***NOT*** provide automatic key storage in a shared location:
+
+* Separate [deployment slots](/azure/app-service/deploy-staging-slots), such as Staging and Production. When the app is swapped between deployment slots, any app using Data Protection won't be able to decrypt stored data using the key ring inside the previous slot. For example, swapping Staging to Production or using A/B testing, Data Protection is not synchronized.
+* Asp.net core apps hosted on multiple VMs that don't use [Application Request Routing cookies]/azure/app-service/manage-automatic-scaling?#how-does-arr-affinity-affect-automatic-scaling), known as an ARR Affinity.
+* 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).
+
+:::moniker-end
+
+[!INCLUDE[](~/security/data-protection/configuration/scaling/includes/scaling7.md)]

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

@@ -0,0 +1,8 @@
+
+:::moniker range="< aspnetcore-8.0"
+
+Duplicate of what we agree on in the V8+ scaling.md file with the following removed
+
+ Newly created Azure Container Apps built using ASP.NET Core Kestrel  8.0 and later . For more information see [Autoscaling considerations
+
+:::moniker-end