Muokkaa

Jaa

How to integrate Azure SignalR with reverse proxies

  • Artikkeli

A reverse proxy server can be used in front of Azure SignalR Service. Reverse proxy servers sit in between the clients and the Azure SignalR service and other services can help in various scenarios. For example, reverse proxy servers can load balance different client requests to different backend services, you can usually configure different routing rules for different client requests, and provide seamless user experience for users accessing different backend services. They can also protect your backend servers from common exploits vulnerabilities with centralized protection control. Services such as Azure Application Gateway, Azure API Management or Akamai can act as reverse proxy servers.

A common architecture using a reverse proxy server with Azure SignalR is as below:

Diagram that shows the architecture using Azure SignalR with a reverse proxy server.

Important

Raw connection strings appear in this article for demonstration purposes only.

A connection string includes the authorization information required for your application to access Azure Web PubSub service. The access key inside the connection string is similar to a root password for your service. In production environments, always protect your access keys. Use Azure Key Vault to manage and rotate your keys securely and secure your connection string using Microsoft Entra ID.

Avoid distributing access keys to other users, hard-coding them, or saving them anywhere in plain text that is accessible to others. Rotate your keys if you believe they may have been compromised.

General practices

There are several general practices to follow when using a reverse proxy in front of SignalR Service.

Raw connection strings appear in this article for demonstration purposes only. In production environments, always protect your access keys. Use Azure Key Vault to manage and rotate your keys securely and secure your connection string using Microsoft Entra ID.

  • Make sure to rewrite the incoming HTTP HOST header with the Azure SignalR service URL, e.g. https://demo.service.signalr.net. Azure SignalR is a multi-tenant service, and it relies on the HOST header to resolve to the correct endpoint. For example, when configuring Application Gateway for Azure SignalR, select Yes for the option Override with new host name.

  • When your client goes through your reverse proxy to Azure SignalR, set ClientEndpoint as your reverse proxy URL. When your client negotiates with your hub server, the hub server will return the URL defined in ClientEndpoint for your client to connect. Check here for more details.

    There are two ways to configure ClientEndpoint:

    • Add a ClientEndpoint section to your ConnectionString: Endpoint=...;AccessKey=...;ClientEndpoint=<reverse-proxy-URL>

    • Configure ClientEndpoint when calling AddAzureSignalR:

      services.AddSignalR().AddAzureSignalR(o =>
{
    o.Endpoints = new Microsoft.Azure.SignalR.ServiceEndpoint[1]
    {
        new Microsoft.Azure.SignalR.ServiceEndpoint("<azure-signalr-connection-string>")
        {
            ClientEndpoint = new Uri("<reverse-proxy-URL>")
        }
    };
})

  • When a client goes through your reverse proxy to Azure SignalR, there are two types of requests:

    • HTTP post request to <reverse-proxy-URL>/client/negotiate/, which we call as negotiate request
    • WebSocket/SSE/LongPolling connection request depending on your transport type to <reverse-proxy-URL>/client/, which we call as connect request.

    Make sure that your reverse proxy supports both transport types for /client/ subpath. For example, when your transport type is WebSocket, make sure your reverse proxy supports both HTTP and WebSocket for /client/ subpath.

    If you have configured multiple SignalR services behind your reverse proxy, make sure negotiate request and connect request with the same asrs_request_id query parameter(meaning they are for the same connection) are routed to the same SignalR service instance.

  • When reverse proxy is used, you can further secure your SignalR service by disabling public network access and using private endpoints to allow only private access from your reverse proxy to your SignalR service through VNet.

Next steps