Application Firewall for Azure SignalR Service

The Application Firewall provides sophisticated control over client connections in a distributed system. Before diving into its functionality and setup, let's clarify what the Application Firewall does not do:

1. It does not replace authentication. The firewall operates behind the client connection authentication layer.
2. It is not related to network layer access control.

The Application Firewall consists of various rule lists. Currently, there are two rule lists called Client Connection Count Rules and Client Traffic Control Rules. Future updates will support more rule lists to control aspects such as connection lifetime.

This guideline is divided into three parts:

1. Introduction to different application firewall rules.
2. Instructions on configuring the rules using the Portal or Bicep on the SignalR service side.
3. Steps to configure the token on the server side.

• An Azure SignalR Service in Premium tier.

Client Connection Count Rules restrict concurrent client connections. When a client attempts to establish a new connection, the rules are checked sequentially. If any rule is violated, the connection is rejected with a status code 429.

This rule limits the concurrent connections of a user. For example, if a user opens multiple browser tabs or logs in using different devices, you can use this rule to restrict the number of concurrent connections for that user.

This rule limits the concurrent connections of the same token to prevent malicious users from reusing tokens to establish infinite connections, which can exhaust connection quota.

More advanced, connections could be grouped into different groups according to custom claim. Connections with the same claim are aggregated to do the check. For example, you could add a ThrottleByJwtCustomClaimRule to allow 5 concurrent connections with custom claim name freeUser.

Client Traffic Control Rules restrict the inbound throughput of client connections. When a client attempts to send a message, the rules are checked sequentially. Within each aggregation window, the message size will be aggregated to check against max inbound message. If any rule is violated, the connection is disconnected.

This rule limits the inbound throughput of a user.

This rule limits the inbound throughput of each token.

This rule limits the inbound throughput of the same claim.

@description('The name for your SignalR service')
param resourceName string = 'contoso'

resource signalr 'Microsoft.SignalRService/signalr@2024-10-01-preview' = {
  name: resourceName
  properties: {
    applicationFirewall:{
        clientConnectionCountRules:[
            // Add or remove rules as needed
            {
              // This rule will be skipped if no userId is set
                type: 'ThrottleByUserIdRule'
                maxCount: 5
            }
            {
                type: 'ThrottleByJwtSignatureRule'
                maxCount: 10
            }
            {
                // This rule will be skipped if no freeUser claim is set
                type: 'ThrottleByJwtCustomClaimRule'
                maxCount: 10
                claimName: 'freeUser'
            }
            {
                // This rule will be skipped if no paidUser claim is set
                type: 'ThrottleByJwtCustomClaimRule'  
                maxCount: 100
                claimName: 'paidUser'
            }
        ]
         clientTrafficControlRules:[
        // Add or remove rules as needed
        {
            // This rule will be skipped if no userId is set
            type: 'TrafficThrottleByUserIdRule'
            // Every minute
            aggregationWindowInSeconds: 60
            // 10MB
            maxInboundMessageBytes: 10485760
        }
        {
            type: 'TrafficThrottleByJwtSignatureRule'
            // Every 30 seconds
            aggregationWindowInSeconds: 30
            // 5MB
            maxInboundMessageBytes: 5242880
        }
        {
            // This rule will be skipped if no freeUser claim is set
            type: 'TrafficThrottleByJwtCustomClaimRule'
            // Every 10 minutes
            aggregationWindowInSeconds: 600
            // 1MB
            maxInboundMessageBytes: 1048576
            claimName: 'freeUser'
        }
        {
            // This rule will be skipped if no paidUser claim is set
            type: 'TrafficThrottleByJwtCustomClaimRule'  
            // Every 30 seconds
            aggregationWindowInSeconds: 30
            // 1MB
            maxInboundMessageBytes: 1048576
            claimName: 'paidUser'
        }
      ]
    }
  }
}

az deployment group create --resource-group MyResourceGroup --template-file main.bicep

The application firewall rules only take effect when the access token contains the corresponding claim. A rule is skipped if the connection does not have the corresponding claim.

Below is an example to add userId or custom claim in the access token in Default Mode:

services.AddSignalR().AddAzureSignalR(options =>
    {
        //  Add necessary claims according to your rules.
        options.ClaimsProvider = context => new[]
        {
            // Add UserId: Used in ThrottleByUserIdRule
            new Claim(ClaimTypes.NameIdentifier, context.Request.Query["username"]),

            // Add unique claim: Ensure uniqueness when using ThrottleByJwtSignatureRule. 
            // The token name is not important. You could change it as you like.
            new Claim("uniqueToken", Guid.NewGuid().ToString()),
           
            // Custom claim: Used in ThrottleByJwtCustomClaimRule
            new Claim("<Custom Claim Name>", "<Custom Claim Value>"),
            // Custom claim example
            new Claim("freeUser", context.Request.Query["username"]),
        };
    });

The logic for Serverless Mode is similar.

For more details, refer to Client negotiation .