Merge pull request #292590 from MicrosoftDocs/main

Publish to live, Friday 4 AM PST, 1/3

Author: ttorble

articles/app-service/overview-app-gateway-integration.md

@@ -131,10 +131,10 @@ To work around the default redirect, you can configure authentication to inspect
 
 In multiple-instance deployments, [session affinity](./configure-common.md?tabs=portal#configure-general-settings) ensures that client requests are routed to the same instance for the life of the session. Session affinity can be configured to adapt the cookie domain to the incoming header from reverse proxy. By configuring [session affinity proxy](./configure-common.md?tabs=portal#configure-general-settings) to true, session affinity looks for `X-Original-Host` or `X-Forwarded-Host` and adapt the cookie domain to the domain found in this header. As a recommended practice when enabling session affinity proxy, you should configure your access restrictions on the site to ensure that traffic is coming from your reverse proxy.
 
-You can also configure `sessionAffinityProxyEnabled` by using the following command:
+You can also configure `clientAffinityProxyEnabled` by using the following command:
 
 ```azurecli-interactive
-az resource update --resource-group myRG --name myWebApp --resource-type "Microsoft.Web/sites" --set properties.sessionAffinityProxyEnabled=true
+az resource update --resource-group myRG --name myWebApp --resource-type "Microsoft.Web/sites" --set properties.clientAffinityProxyEnabled=true
 ```
 
 ## Next steps

articles/azure-signalr/howto-network-access-control.md

@@ -91,7 +91,7 @@ resource signalr 'Microsoft.SignalRService/SignalR@2024-08-01-preview' = {
 
 You can configure rules to allow or deny specified request types for both the public network and each [private endpoint](howto-private-endpoints.md).
 
-For example, [Server Connections](signalr-concept-internals.md#application-server-connections) are typically high-privileged. To enhance security, you may want to restrict their origin. You can configure rules to block all Server Connections from public network, and only allow they originate from a specifiec virtual network.
+For example, [Server Connections](signalr-concept-internals.md#application-server-connections) are typically high-privileged. To enhance security, you may want to restrict their origin. You can configure rules to block all Server Connections from public network, and only allow they originate from a specific virtual network.
 
 If no rule matches, the default action is applied.
 
@@ -114,7 +114,7 @@ If no rule matches, the default action is applied.
 
 ### [Configure Request Type Rules via Bicep](#tab/bicep)
 
-The following template denies all requests from the public network except client connections. Additionally, it allows only Server Connections, REST API calls, and Trace calls from a specific private endpoint.
+The following template denies all requests from the public network except Client Connections. Additionally, it allows only Server Connections, REST API calls, and Trace calls from a specific private endpoint.
 
 The name of the private endpoint connection can be inspected in the `privateEndpointConnections` sub-resource. It's automatically generated by the system.
 
@@ -130,8 +130,8 @@ resource signalr 'Microsoft.SignalRService/SignalR@2024-08-01-preview' = {
         }
         privateEndpoints: [
             {
-                name: 'foo.8e4d6671-8d62-4bb7-8c41-827dde9c1a05'
-                allow: ['ServerConnection', 'ClientConnection', 'RESTAPI', 'Trace']
+                name: 'foo.0000aaaa-11bb-cccc-dd22-eeeeee333333'
+                allow: ['ServerConnection', 'RESTAPI', 'Trace']
             }
         ]
     }

articles/azure-signalr/signalr-howto-troubleshoot-guide.md

@@ -311,8 +311,8 @@ This issue often occurs when someone establishes a SignalR client connection in
 #### Solution
 
 * Remember to close client connection if you use SignalR clients in Azure function or use SignalR client as a singleton.
-* Instead of using SignalR clients in Azure function, you can create SignalR clients anywhere else and use [Azure Functions Bindings for Azure SignalR Service](https://github.com/Azure/azure-functions-signalrservice-extension) to [negotiate](https://github.com/Azure/azure-functions-signalrservice-extension/blob/dev/samples/simple-chat/csharp/FunctionApp/Functions.cs#L22) the client to Azure SignalR. And you can also utilize the binding to [send messages](https://github.com/Azure/azure-functions-signalrservice-extension/blob/dev/samples/simple-chat/csharp/FunctionApp/Functions.cs#L40). Samples to negotiate client and send messages can be found [here](https://github.com/Azure/azure-functions-signalrservice-extension/tree/dev/samples). Further information can be found [here](https://github.com/Azure/azure-functions-signalrservice-extension).
-* When you use SignalR clients in Azure function, there might be a better architecture to your scenario. Check if you design a proper serverless architecture. You can refer to [Real-time serverless applications with the SignalR Service bindings in Azure Functions](https://www.nuget.org/packages/Microsoft.Azure.WebJobs.Extensions.SignalRService).
+* Instead of using SignalR clients in Azure function, you can create SignalR clients anywhere else and use [Azure Functions Bindings for Azure SignalR Service](https://github.com/Azure/azure-sdk-for-net/tree/main/sdk/signalr/Microsoft.Azure.WebJobs.Extensions.SignalRService) to [negotiate](https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/signalr/Microsoft.Azure.WebJobs.Extensions.SignalRService/tests/Samples/BasicNegotiate.cs) the client to Azure SignalR. And you can also utilize the binding to [send messages](https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/signalr/Microsoft.Azure.WebJobs.Extensions.SignalRService/tests/Samples/SendMessages.cs). Samples to negotiate client and send messages can be found [here](https://github.com/Azure/azure-sdk-for-net/tree/main/sdk/signalr/Microsoft.Azure.WebJobs.Extensions.SignalRService/tests/Samples). Further information can be found [here](signalr-concept-serverless-development-config.md).
+* When you use SignalR clients in Azure function, there might be a better architecture to your scenario. Check if you design a proper serverless architecture. You can refer to [Real-time apps with Azure SignalR Service and Azure Functions](signalr-concept-azure-functions.md).
 
 <a name="server_connection_drop"></a>
 

articles/azure-web-pubsub/howto-secure-network-access-control.md

@@ -1,55 +1,205 @@
 ---
 title: Manage network access control to an endpoint
 description: Learn how to control network access to your Azure Web PubSub resource.
-author: yjin81
-ms.author: yajin1
+author: ArchangelSDY
+ms.author: dayshen
 ms.service: azure-web-pubsub
 ms.topic: how-to 
 ms.date: 08/16/2024
 ---
 
 # Manage network access control
 
+Azure Web PubSub allows you to secure and manage access to your service endpoint based on request types and network subsets. When you configure network access control rules, only applications making requests from the specified networks can access your Azure Web PubSub instance.
+
 You can configure Azure Web PubSub to secure and control the level of access to your service endpoint based on the request type and subset of networks used. When network rules are configured, only applications that request data over the specified set of networks can access your Web PubSub resource.
 
-Azure Web PubSub has a public endpoint that is accessible through the internet. You can also create a [private endpoint for your Web PubSub resource](howto-secure-private-endpoints.md). A private endpoint assigns a private IP address from your virtual network to the Web PubSub resource. It also secures all traffic between your virtual network and the Web PubSub resource over a private link. The Web PubSub network access control provides access control for both a public endpoint and for private endpoints.
+  :::image type="content" alt-text="Screenshot showing network access control decision flow chart." source="media\howto-secure-network-access-control\network-access-control-decision-flow-chart.png" :::
+
+
+## Public network access
+
+We offer a single, unified switch to simplify the configuration of public network access. The switch has following options:
+
+* Disabled: Completely blocks public network access. All other network access control rules are ignored for public networks.
+* Enabled: Allows public network access, which is further regulated by additional network access control rules.
+
+### [Configure public network access via portal](#tab/azure-portal)
+
+1. Go to the Azure Web PubSub instance you want to secure.
+1. Select **Networking** from the left side menu. Select **Public access** tab:
+
+  :::image type="content" alt-text="Screenshot showing how to configure public network access." source="media\howto-secure-network-access-control\portal-public-network-access.png" :::
+
+1. Select **Disabled** or **Enabled**.
+
+1. Select **Save** to apply your changes.
+
+### [Configure public network access via bicep](#tab/bicep)
+
+The following template disables public network access:
+
+```bicep
+resource webpubsub 'Microsoft.SignalRService/WebPubSub@2024-08-01-preview' = {
+  name: 'foobar'
+  location: 'eastus'
+  properties: {
+    publicNetworkAccess: 'Disabled'
+  }
+}
+```
+
+-----
+
+
+## Default action
+
+The default action is applied when no other rule matches.
+
+### [Configure default action via portal](#tab/azure-portal)
 
-Optionally, you can choose to allow or deny certain types of requests for a public endpoint and for each private endpoint.
+1. Go to the Azure Web PubSub instance you want to secure.
+1. Select **Network access control** from the left side menu.
 
-An application that accesses a Web PubSub resource when network access control rules are in effect still requires proper authorization for the request.
+  :::image type="content" alt-text="Screenshot showing default action on portal." source="media/howto-secure-network-access-control/portal-default-action.png" :::
 
-The next sections describe your two options to control access to your Web PubSub resources:
+1. To edit the default action, toggle the **Allow/Deny** button.
+1. Select **Save** to apply your changes.
+
+### [Configure default action via bicep](#tab/bicep)
 
-- Deny all requests that originate in a public endpoint.
-- Allow only client connections from a public network.
+The following template sets the default action to `Deny`.
 
-## Deny all public traffic
+```bicep
+resource webpubsub 'Microsoft.SignalRService/WebPubSub@2024-08-01-preview' = {
+  name: 'foobar'
+  location: 'eastus'
+  properties: {
+    networkACLs: {
+        defaultAction: 'Deny'
+    }
+}
+```
 
-To completely deny all public traffic, first configure the public network rule to allow no request type. Then, configure rules that grant access to traffic from specific virtual networks. This configuration enables you to build a secure network boundary for your applications.
+-----
 
-## Allow only client connections from a public network
 
-In this scenario, you configure the public network rule to allow only client connections from a public network. You can then configure private network rules to allow other types of requests that originate from a specific virtual network. This configuration hides your app servers on a public network and establishes secure connections between your app servers and Azure Web PubSub.
+## Request type rules
 
-## Manage network access control in the Azure portal
+You can configure rules to allow or deny specified request types for both the public network and each [private endpoint](howto-secure-private-endpoints.md).
 
-You can manage network access control for Azure Web PubSub by using the Azure portal.
+For example, [REST API calls](reference-rest-api-data-plane.md) are typically high-privileged. To enhance security, you may want to restrict their origin. You can configure rules to block all REST API calls from public network, and only allow they originate from a specific virtual network.
 
-1. In the Azure portal, go to the Web PubSub service you want to secure.
+If no rule matches, the default action is applied.
 
-1. On the left menu under **Settings**, select **Network access control**.
+### [Configure request type rules via portal](#tab/azure-portal)
 
-1. To edit the default action, select **Default action**.
+1. Go to the Azure Web PubSub instance you want to secure.
+1. Select **Network access control** from the left side menu.
 
-    > [!TIP]
-    > The default action is the action that you take when no access control list (ACL) rules match. For example, if the default action is **Deny**, request types that are not explicitly approved are denied.
+  :::image type="content" alt-text="Screenshot showing request type rules on portal." source="media/howto-secure-network-access-control/portal-request-type-rules.png" :::
 
-    :::image type="content" source="./media/howto-secure-network-access-control/portal-network-access-control.png" alt-text="Screenshot that shows the Network access control pane in the Azure portal.":::
+1. To edit public network rule, select allowed types of requests under **Public network**.
 
-1. To edit a public network rule, under **Public network**, select the types of requests that you want to allow.
+  :::image type="content" alt-text="Screenshot of selecting allowed request types for public network on portal." source="media/howto-secure-network-access-control/portal-public-network.png" :::
 
-    :::image type="content" source="./media/howto-secure-network-access-control/portal-public-network.png" alt-text="Screenshot that shows editing a public network access control list in the Azure portal.":::
+1. To edit private endpoint network rules, select allowed types of requests in each row under **Private endpoint connections**.
 
-1. To edit private endpoint network rules, under **Private endpoint connections**, select the allowed types of requests in each row.
+  :::image type="content" alt-text="Screenshot of selecting allowed request types for private endpoints on portal." source="media/howto-secure-network-access-control/portal-private-endpoint.png" :::
 
 1. Select **Save** to apply your changes.
+
+### [Configure request type rules via bicep](#tab/bicep)
+
+The following template denies all requests from the public network except Client Connections. Additionally, it allows only REST API calls, and Trace calls from a specific private endpoint.
+
+The name of the private endpoint connection can be inspected in the `privateEndpointConnections` sub-resource. It's automatically generated by the system.
+
+```bicep
+resource webpubsub 'Microsoft.SignalRService/WebPubSub@2024-08-01-preview' = {
+  name: 'foobar'
+  location: 'eastus'
+  properties: {
+    networkACLs: {
+        defaultAction: 'Deny'
+        publicNetwork: {
+            allow: ['ClientConnection']
+        }
+        privateEndpoints: [
+            {
+                name: 'foo.0000aaaa-11bb-cccc-dd22-eeeeee333333'
+                allow: ['RESTAPI', 'Trace']
+            }
+        ]
+    }
+}
+```
+
+-----
+
+
+## IP rules
+
+IP rules allow you to grant or deny access to specific public internet IP address ranges. These rules can be used to permit access for certain internet-based services and on-premises networks or to block general internet traffic.
+
+The following restrictions apply:
+
+* You can configure up to 30 rules.
+* Address ranges must be specified using [CIDR notation](https://tools.ietf.org/html/rfc4632), such as `16.17.18.0/24`. Both IPv4 and IPv6 addresses are supported.
+* IP rules are evaluated in the order they are defined. If no rule matches, the default action is applied.
+* IP rules apply only to public traffic and cannot block traffic from private endpoints.
+
+### [Configure IP rules via portal](#tab/azure-portal)
+
+1. Go to the Azure Web PubSub instance you want to secure.
+1. Select **Networking** from the left side menu. Select **Access control rules** tab:
+
+   :::image type="content" alt-text="Screenshot showing how to configure IP rules." source="media\howto-secure-network-access-control\portal-ip-rules.png" :::
+
+1. Edit the list under **IP rules** section.
+
+1. Select **Save** to apply your changes.
+
+### [Configure IP rules via bicep](#tab/bicep)
+
+The following template has these effects:
+
+* Requests from `123.0.0.0/8` and `2603::/8` are allowed.
+* Requests from all other IP ranges are denied.
+
+```bicep
+resource webpubsub 'Microsoft.SignalRService/WebPubSub@2024-08-01-preview' = {
+  name: 'foobar'
+  location: 'eastus'
+  properties: {
+    networkACLs: {
+      defaultAction: 'Deny'
+      ipRules: [
+        {
+          value: '123.0.0.0/8'
+          action: 'Allow'
+        }
+        {
+          value: '2603::/8'
+          action: 'Allow'
+        }
+        {
+          value: '0.0.0.0/0'
+          action: 'Deny'
+        }
+        {
+          value: '::/0'
+          action: 'Deny'
+        }
+      ]
+    }
+  }
+}
+```
+
+-----
+
+
+## Next steps
+
+Learn more about [Azure Private Link](../private-link/private-link-overview.md).