Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into nw-vnetflow

Author: halkazwini

articles/application-gateway/application-gateway-secure-flag-session-affinity.md

@@ -0,0 +1,55 @@
+---
+title: Setting HTTPOnly or Secure flag for Session Affinity cookie
+titleSuffix: Azure Application Gateway
+description: Learn how to set HTTPOnly or Secure flag for Session Affinity cookie
+services: application-gateway
+author: jaesoni
+ms.service: azure-application-gateway
+ms.topic: how-to
+ms.date: 10/22/2024
+ms.author: jaysoni 
+---
+
+# Setting HTTPOnly or Secure flag for Session Affinity cookie
+In this guide you learn to create a Rewrite set for your Application Gateway and configure Secure and HttpOnly [ApplicationGatewayAffinity cookie](configuration-http-settings.md#cookie-based-affinity).
+
+
+## Prerequisites
+* You must have an Azure subscription. You can create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.
+* An existing Application Gateway resource configured with at least one Listener, Rule, Backend Setting and Backend Pool configuration. If you don't have one, you can create one by following the [QuickStart guide](quick-create-portal.md).
+
+## Creating a Rewrite set
+
+1. Sign in to the Azure portal.
+1. Navigate to the required Application Gateway resource.
+1. Select Rewrites in the left pane.
+1. Select Rewrite set.
+1. Under the Name and Association tab
+    1. Specify a name for this new rewrite set.
+    1. Select the routing rules for which you wish to rewrite the ApplicationGatewayAffinity cookie's flag.
+    1. Select Next.
+1. Select "Add rewrite rule"
+    1. Enter a name for the rewrite rule.
+    1. Enter a numeric value for Rule Sequence field.
+1. Select "Add condition"
+1. Now open the "If" condition box and use the following details.
+    1. Type of variable to check - HTTP header
+    1. Header type - Response header
+    1. Header name - Common header
+    1. Common header - Set-Cookie
+    1. Case-sensitive - No
+    1. Operator - equal (=)
+    1. Pattern to match - (.*)
+    1. To save these details, select **OK**.
+1. Go to the **Then** box to specify action details.
+    1. Rewrite type - Response header
+    1. Action type - Set
+    1. Header name - Common header
+    1. Common header - Set-Cookie
+    1. Header value - {http_resp_Set-Cookie_1}; HttpOnly; Secure
+    1. Select **OK**
+1. Select Update to save the rewrite set configurations.
+
+
+## Next steps
+[Visit other configurations of a Backend Setting](configuration-http-settings.md)

articles/application-gateway/media/application-gateway-create-probe-portal/figure6.png

@@ -5,7 +5,7 @@ services: application-gateway
 author: greg-lindsay
 ms.service: azure-application-gateway
 ms.topic: how-to
-ms.date: 4/05/2021
+ms.date: 10/22/2024
 ms.author: greglin
 ---
 
@@ -72,7 +72,7 @@ In the below example whenever the request URL contains */article*, the URL path
 
     f. Enter a regular expression pattern. In this example, we'll use the pattern `.*article/(.*)/(.*)`
 
-      ( ) is used to capture the substring for later use in composing the expression for rewriting the URL path. For more information, see [here](rewrite-http-headers-url.md#capturing).
+      ( ) is used to capture the substring for later use in composing the expression for rewriting the URL path. For more information, see [Pattern matching and capturing](rewrite-http-headers-url.md#pattern-matching-and-capturing).
 
     g. Select **OK**.
 

articles/application-gateway/rewrite-http-headers-url.md

@@ -267,6 +267,8 @@
           href: add-http-header-rewrite-rule-powershell.md
         - name: Create and rewrite HTTP headers
           href: tutorial-http-header-rewrite-powershell.md
+        - name: Add secure flag for cookies 
+          href: application-gateway-secure-flag-session-affinity.md       
     - name: URL rewrite
       items:
         - name: Azure portal

articles/application-gateway/rewrite-url-portal.md

@@ -159,7 +159,7 @@ You can also use the [Azure Key Vault solution in Azure Monitor](/azure/key-vaul
 #### Vault
 **[Vaults](/azure/key-vault/general/overview)** provide a multi-tenant, low-cost, easy to deploy, zone-resilient (where available), and highly available key management solution suitable for most common cloud application scenarios. Vaults can store and safeguard [secrets, keys, and certificates](/azure/key-vault/general/about-keys-secrets-certificates). They can be either software-protected (standard tier) or HSM-protected (premium tier). For a comparison between the standard and premium tiers, see the [Azure Key Vault pricing page](https://azure.microsoft.com/pricing/details/key-vault/). Software-protected secrets, keys, and certificates are safeguarded by Azure, using industry-standard algorithms and key lengths. If you require extra assurances, you can choose to safeguard your secrets, keys, and certificates in vaults protected by multi-tenant HSMs. The corresponding HSMs are validated according to the [FIPS 140 standard](/azure/compliance/offerings/offering-fips-140-2), and have an overall Security Level 2 rating, which includes requirements for physical tamper evidence and role-based authentication.
 
-Vaults enable support for [customer-managed keys](../security/fundamentals/encryption-models.md) (CMK) where you can control your own keys in HSMs, and use them to encrypt data at rest for [many Azure services](../security/fundamentals/encryption-models.md#supporting-services). As mentioned previously, you can [import or generate encryption keys](/azure/key-vault/keys/hsm-protected-keys) in HSMs ensuring that keys never leave the HSM boundary to support *bring your own key (BYOK)* scenarios.
+Vaults enable support for [customer-managed keys](../security/fundamentals/encryption-models.md) (CMK) where you can control your own keys in HSMs, and use them to encrypt data at rest for [many Azure services](../security/fundamentals/encryption-models.md#services-supporting-customer-managed-keys-cmks). As mentioned previously, you can [import or generate encryption keys](/azure/key-vault/keys/hsm-protected-keys) in HSMs ensuring that keys never leave the HSM boundary to support *bring your own key (BYOK)* scenarios.
 
 Key Vault can handle requesting and renewing certificates in vaults, including Transport Layer Security (TLS) certificates, enabling you to enroll and automatically renew certificates from supported public Certificate Authorities. Key Vault certificates support provides for the management of your X.509 certificates, which are built on top of keys and provide an automated renewal feature. Certificate owner can [create a certificate](/azure/key-vault/certificates/create-certificate) through Azure Key Vault or by importing an existing certificate. Both self-signed and Certificate Authority generated certificates are supported. Moreover, the Key Vault certificate owner can implement secure storage and management of X.509 certificates without interaction with private keys.
 
@@ -179,7 +179,7 @@ When a managed HSM is created, the requestor also provides a list of data plane
 > [!IMPORTANT]
 > Unlike with key vaults, granting your users management plane access to a managed HSM doesn't grant them any access to data plane to access keys or data plane role assignments managed HSM local RBAC. This isolation is implemented by design to prevent inadvertent expansion of privileges affecting access to keys stored in managed HSMs.
 
-As mentioned previously, managed HSM supports [importing keys generated](/azure/key-vault/managed-hsm/hsm-protected-keys-byok) in your on-premises HSMs, ensuring the keys never leave the HSM protection boundary, also known as *bring your own key (BYOK)* scenario. Managed HSM supports integration with Azure services such as [Azure Storage](../storage/common/customer-managed-keys-overview.md), [Azure SQL Database](/azure/azure-sql/database/transparent-data-encryption-byok-overview), [Azure Information Protection](/azure/information-protection/byok-price-restrictions), and others. For a more complete list of Azure services that work with Managed HSM, see [Data encryption models](../security/fundamentals/encryption-models.md#supporting-services).
+As mentioned previously, managed HSM supports [importing keys generated](/azure/key-vault/managed-hsm/hsm-protected-keys-byok) in your on-premises HSMs, ensuring the keys never leave the HSM protection boundary, also known as *bring your own key (BYOK)* scenario. Managed HSM supports integration with Azure services such as [Azure Storage](../storage/common/customer-managed-keys-overview.md), [Azure SQL Database](/azure/azure-sql/database/transparent-data-encryption-byok-overview), [Azure Information Protection](/azure/information-protection/byok-price-restrictions), and others. For a more complete list of Azure services that work with Managed HSM, see [Data encryption models](../security/fundamentals/encryption-models.md#services-supporting-customer-managed-keys-cmks).
 
 Managed HSM enables you to use the established Azure Key Vault API and management interfaces. You can use the same application development and deployment patterns for all your applications irrespective of the key management solution: multi-tenant vault or single-tenant managed HSM.