Partager via

Comment intégrer Azure SignalR avec des proxys inverses

  • Article

Un serveur proxy inverse peut être utilisé devant Azure SignalR Service. Les serveurs proxy inverses se trouvent entre les clients et le service Azure SignalR, et d’autres services peuvent aider dans divers scénarios. Par exemple, des serveurs proxy inverses peuvent équilibrer la charge de différentes demandes client à différents services principaux, et vous pouvez généralement configurer différentes règles de routage pour différentes demandes client, ainsi que fournir une expérience utilisateur transparente pour les utilisateurs accédant à différents services principaux. Ils peuvent également protéger vos serveurs principaux contre des vulnérabilités courantes aux attaques avec un contrôle de protection centralisé. Des services tels que Azure Application Gateway, Gestion des API Azure ou Akamai peuvent agir en tant que serveurs proxy inverses.

Une architecture courante utilisant un serveur proxy inverse avec Azure SignalR se présente comme suit :

Diagramme montrant l’architecture utilisant Azure SignalR avec un serveur proxy inverse.

Important

Des chaînes de connexion brutes sont utilisées dans cet article uniquement à des fins de démonstration.

Une chaîne de connexion contient les informations d’autorisation requises pour que votre application accède au service Azure Web PubSub. La clé d’accès à l’intérieur dans la chaîne de connexion est semblable à un mot de passe racine pour votre service. Dans les environnements de production, protégez toujours vos clés d’accès. Utilisez Azure Key Vault pour gérer et permuter vos clés de façon sécurisée, sécuriser votre chaîne de connexion en utilisant Microsoft Entra ID, et autoriser l’accès avec Microsoft Entra ID.

Évitez de distribuer des clés d’accès à d’autres utilisateurs, de les coder en dur ou de les enregistrer en texte brut dans un emplacement accessible à d’autres personnes. Effectuez une rotation de vos clés si vous pensez qu’elles ont pu être compromises.

Pratiques générales

Il existe plusieurs pratiques générales à suivre lors de l’utilisation d’un proxy inverse devant SignalR Service.

Des chaînes de connexion brutes sont utilisées dans cet article uniquement à des fins de démonstration. Dans les environnements de production, protégez toujours vos clés d’accès. Utilisez Azure Key Vault pour gérer et permuter vos clés de façon sécurisée, sécuriser votre chaîne de connexion en utilisant Microsoft Entra ID, et autoriser l’accès avec Microsoft Entra ID.

  • Veillez à réécrire l’en-tête HTTP HOST entrant avec l’URL du service Azure SignalR, par exemple https://demo.service.signalr.net. Azure SignalR est un service mutualisé, qui s’appuie sur l’en-tête HOST pour résoudre le point de terminaison approprié. Par exemple, lors de la configuration d’Application Gateway pour Azure SignalR, sélectionnez Oui pour l’option Remplacer par le nouveau nom d’hôte.

  • Lorsque votre client transite par votre proxy inverse vers Azure SignalR, définissez ClientEndpoint comme URL de proxy inverse. Lorsque votre client négocie avec votre serveur hub, celui-ci retourne l’URL définie dans ClientEndpoint pour que votre client se connecte. Cliquez ici pour plus de détails.

    Il existe deux façons de configurer ClientEndpoint :

    • Ajouter une section ClientEndpoint à votre ConnectionString : Endpoint=...;AccessKey=...;ClientEndpoint=<reverse-proxy-URL>

    • Configurer ClientEndpoint lors de l’appel de 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>")
        }
    };
})

  • Quand un client transite par votre proxy inverse vers Azure SignalR, il existe deux types de requêtes :

    • Requête HTTP POST à <reverse-proxy-URL>/client/negotiate/, que nous appelons requête de négociation
    • Requête de connexion WebSocket/SSE/LongPolling en fonction de votre type de transport vers <reverse-proxy-URL>/client/, que nous appelons requête de connexion.

    Assurez-vous que votre proxy inverse prend en charge les deux types de transport pour le sous-tracé /client/. Par exemple, lorsque votre type de transport est WebSocket, assurez-vous que votre proxy inverse prend en charge HTTP et WebSocket pour le sous-tracé /client/.

    Si vous avez configuré plusieurs services SignalR derrière votre proxy inverse, assurez-vous que les requêtes negotiate et connect avec le même paramètre de requête asrs_request_id (indiquant qu’elles concernent la même connexion) sont routées vers la même instance de service SignalR.

  • Quand un proxy inverse est utilisé, vous pouvez sécuriser davantage votre service SignalR en désactivant l’accès au réseau public et en utilisant des points de terminaison privés pour autoriser uniquement un accès privé de votre proxy inverse à votre service SignalR via un réseau virtuel.

Étapes suivantes