Merge pull request #104834 from surajmb/samesiteappgwupdate

SameSite changes for AppGw

Author: PRMerger6

articles/application-gateway/configuration-overview.md

@@ -206,7 +206,7 @@ For a path-based rule, add multiple back-end HTTP settings that correspond to ea
 
 If redirection is configured for a basic rule, all requests on the associated listener are redirected to the target. This is *global* redirection. If redirection is configured for a path-based rule, only requests in a specific site area are redirected. An example is a shopping cart area that's denoted by */cart/\**. This is *path-based* redirection.
 
-For more information about redirects, see [Application Gateway redirect overview](https://docs.microsoft.com/azure/application-gateway/redirect-overview).
+For more information about redirects, see [Application Gateway redirect overview](redirect-overview.md).
 
 #### Redirection type
 
@@ -223,32 +223,44 @@ Choose listener as the redirection target to redirect traffic from one listener
 ![Application Gateway components dialog box](./media/configuration-overview/configure-redirection.png)
 
 For more information about HTTP-to-HTTPS redirection, see:
-- [HTTP-to-HTTPS redirection by using the Azure portal](https://docs.microsoft.com/azure/application-gateway/redirect-http-to-https-portal)
-- [HTTP-to-HTTPS redirection by using PowerShell](https://docs.microsoft.com/azure/application-gateway/redirect-http-to-https-powershell)
-- [HTTP-to-HTTPS redirection by using the Azure CLI](https://docs.microsoft.com/azure/application-gateway/redirect-http-to-https-cli)
+- [HTTP-to-HTTPS redirection by using the Azure portal](redirect-http-to-https-portal.md)
+- [HTTP-to-HTTPS redirection by using PowerShell](redirect-http-to-https-powershell.md)
+- [HTTP-to-HTTPS redirection by using the Azure CLI](redirect-http-to-https-cli.md)
 
 ##### External site
 
 Choose external site when you want to redirect the traffic on the listener that's associated with this rule to an external site. You can choose to include the query string from the original request in the request that's forwarded to the redirection target. You can't forward the path to the external site that was in the original request.
 
 For more information about redirection, see:
-- [Redirect traffic to an external site by using PowerShell](https://docs.microsoft.com/azure/application-gateway/redirect-external-site-powershell)
-- [Redirect traffic to an external site by using the CLI](https://docs.microsoft.com/azure/application-gateway/redirect-external-site-cli)
+- [Redirect traffic to an external site by using PowerShell](redirect-external-site-powershell.md)
+- [Redirect traffic to an external site by using the CLI](redirect-external-site-cli.md)
 
 #### Rewrite the HTTP header setting
 
 This setting adds, removes, or updates HTTP request and response headers while the request and response packets move between the client and back-end pools. For more information, see:
 
- - [Rewrite HTTP headers overview](https://docs.microsoft.com/azure/application-gateway/rewrite-http-headers)
- - [Configure HTTP header rewrite](https://docs.microsoft.com/azure/application-gateway/rewrite-http-headers-portal)
+ - [Rewrite HTTP headers overview](rewrite-http-headers.md)
+ - [Configure HTTP header rewrite](rewrite-http-headers-portal.md)
 
 ## HTTP settings
 
 The application gateway routes traffic to the back-end servers by using the configuration that you specify here. After you create an HTTP setting, you must associate it with one or more request-routing rules.
 
 ### Cookie-based affinity
 
-This feature is useful when you want to keep a user session on the same server. Gateway-managed cookies let the application gateway direct subsequent traffic from a user session to the same server for processing. This is important when session state is saved locally on the server for a user session. If the application can't handle cookie-based affinity, you can't use this feature. To use it, make sure that the clients support cookies.
+Azure Application Gateway uses gateway managed cookies for maintaining user sessions. When a user sends the first request to Application Gateway, it sets an affinity cookie in the response with a hash value which contains the session details, so that the subsequent requests carrying the affinity cookie will be routed to the same backend server for maintaining stickiness. 
+
+This feature is useful when you want to keep a user session on the same server and when session state is saved locally on the server for a user session. If the application can't handle cookie-based affinity, you can't use this feature. To use it, make sure that the clients support cookies.
+
+Starting from **17th February 2020**, the [Chromium](https://www.chromium.org/Home) [v80 update](https://chromiumdash.appspot.com/schedule) brings a mandate where HTTP cookies without SameSite attribute to be treated as SameSite=Lax. In case of CORS (Cross-Origin Resource Sharing) requests, if the cookie has to be sent in a third-party context, it has to use “SameSite=None; Secure” attributes and it should be sent over HTTPS only. Otherwise, in a HTTP only scenario, the browser won’t send the cookies in the third-party context. The goal of this update from Chrome is to enhance security and to avoid Cross-Site Request Forgery (CSRF) attacks. 
+
+To support this change, Application Gateway (all the SKU types) will be injecting another identical cookie called **ApplicationGatewayAffinityCORS** in addition to the existing **ApplicationGatewayAffinity** cookie, which is similar, but this cookie will now have two more attributes **"SameSite=None; Secure"** added to it so that sticky session can be maintained even for cross-origin requests.
+
+Please note that the default affinity cookie name is **ApplicationGatewayAffinity** and this can be changed by the users. In case you are using a custom affinity cookie name, an additional cookie will be added with CORS as suffix, for example, **CustomCookieNameCORS**.
+
+> [!NOTE]
+> It is mandatory that if the attribute **SameSite=None** is set, the cookie also should contain the **Secure** flag and should be sent over **HTTPS**. So if session affinity is required over CORS, you must migrate your workload to HTTPS. 
+Please refer to SSL offload and End-to-End SSL documentation for Application Gateway here – [Overview](ssl-overview.md), [How-to configure SSL offload](create-ssl-portal.md), [How-to configure End-to-End SSL](end-to-end-ssl-portal.md).
 
 ### Connection draining
 
@@ -258,7 +270,7 @@ Connection draining helps you gracefully remove back-end pool members during pla
 
 Application Gateway supports both HTTP and HTTPS for routing requests to the back-end servers. If you choose HTTP, traffic to the back-end servers is unencrypted. If unencrypted communication isn't acceptable, choose HTTPS.
 
-This setting combined with HTTPS in the listener supports [end-to-end SSL](https://docs.microsoft.com/azure/application-gateway/ssl-overview). This allows you to securely transmit sensitive data encrypted to the back end. Each back-end server in the back-end pool that has end-to-end SSL enabled must be configured with a certificate to allow secure communication.
+This setting combined with HTTPS in the listener supports [end-to-end SSL](ssl-overview.md). This allows you to securely transmit sensitive data encrypted to the back end. Each back-end server in the back-end pool that has end-to-end SSL enabled must be configured with a certificate to allow secure communication.
 
 ### Port
 
@@ -297,7 +309,7 @@ This is a UI only shortcut that selects the two required settings for the Azure
 
 ### Use custom probe
 
-This setting associates a [custom probe](https://docs.microsoft.com/azure/application-gateway/application-gateway-probe-overview#custom-health-probe) with an HTTP setting. You can associate only one custom probe with an HTTP setting. If you don't explicitly associate a custom probe, the [default probe](https://docs.microsoft.com/azure/application-gateway/application-gateway-probe-overview#default-health-probe-settings) is used to monitor the health of the back end. We recommend that you create a custom probe for greater control over the health monitoring of your back ends.
+This setting associates a [custom probe](application-gateway-probe-overview.md#custom-health-probe) with an HTTP setting. You can associate only one custom probe with an HTTP setting. If you don't explicitly associate a custom probe, the [default probe](application-gateway-probe-overview.md#default-health-probe-settings) is used to monitor the health of the back end. We recommend that you create a custom probe for greater control over the health monitoring of your back ends.
 
 > [!NOTE]
 > The custom probe doesn't monitor the health of the back-end pool unless the corresponding HTTP setting is explicitly associated with a listener.
@@ -331,7 +343,7 @@ After you create a back-end pool, you must associate it with one or more request
 
 ## Health probes
 
-An application gateway monitors the health of all resources in its back end by default. But we strongly recommend that you create a custom probe for each back-end HTTP setting to get greater control over health monitoring. To learn how to configure a custom probe, see [Custom health probe settings](https://docs.microsoft.com/azure/application-gateway/application-gateway-probe-overview#custom-health-probe-settings).
+An application gateway monitors the health of all resources in its back end by default. But we strongly recommend that you create a custom probe for each back-end HTTP setting to get greater control over health monitoring. To learn how to configure a custom probe, see [Custom health probe settings](application-gateway-probe-overview.md#custom-health-probe-settings).
 
 > [!NOTE]
 > After you create a custom health probe, you need to associate it to a back-end HTTP setting. A custom probe won't monitor the health of the back-end pool unless the corresponding HTTP setting is explicitly associated with a listener using a rule.