Guide pratique pour utiliser Azure SignalR Service avec Azure Application Gateway
Application Gateway est un équilibreur de charge de trafic web qui vous permet de gérer le trafic vers vos applications web. L’utilisation d’Application Gateway avec SignalR Service vous permet d’effectuer les opérations suivantes :
- Protéger vos applications contre des vulnérabilités web courantes.
- Obtenir un équilibrage de charge au niveau application pour vos applications évolutives et hautement disponibles.
- Configurer une sécurité de bout en bout.
- Personnaliser le nom de domaine.
Cet article comprend deux parties :
- La première partie montre comment configurer Application Gateway pour permettre aux clients d’accéder à SignalR via Application Gateway.
- La seconde partie montre comment sécuriser SignalR Service en ajoutant un contrôle d’accès à SignalR Service et en n’autorisant que le trafic en provenance d’Application Gateway.
Des chaînes de connexion brutes sont utilisées dans cet article à des fins de démonstration uniquement. 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.
Installer et configurer Application Gateway
Créer une instance SignalR Service
- Suivez l’article et créez une instance SignalR Service ASRS1
Créer une instance Application Gateway
À partir du portail, créez une instance Application Gateway AG1 :
Dans le portail Azure, recherchez Application Gateway, puis Créer.
Sous l’onglet Informations de base, pour les paramètres de passerelle applicative, utilisez les valeurs suivantes :
Abonnement, Groupe de ressources et Région : paramètres identiques à ceux choisis pour SignalR Service.
Nom de passerelle applicative : AG1.
Réseau virtuel : sélectionnez Créer, puis, dans la fenêtre Créer un réseau virtuel qui s’ouvre, entrez les valeurs suivantes pour créer le réseau virtuel et deux sous-réseaux, l’un pour la passerelle applicative et l’autre pour les serveurs principaux.
Nom : entrez VN1 comme nom du réseau virtuel.
Sous-réseaux : mettez à jour la grille Sous-réseaux avec les 2 sous-réseaux ci-dessous.
Nom du sous-réseau Plage d’adresses Remarque myAGSubnet (plage d’adresses) Sous-réseau pour la passerelle applicative. Le sous-réseau de passerelle d’application peut contenir uniquement des passerelles d’application. Aucune autre ressource n’est autorisée. myBackendSubnet (autre plage d’adresses) Sous-réseau pour l’instance Azure SignalR.
Acceptez les valeurs par défaut pour les autres paramètres, puis sélectionnez Suivant : Serveurs frontaux.
Sous l’onglet Serveurs frontaux :
- Type d’adresse IP de serveur frontal : Publique.
- Sélectionnez Ajouter nouveau pour Adresse IP publique, entrez myAGPublicIPAddress comme nom d’adresse IP publique, puis sélectionnez OK.
- Sélectionnez Suivant : Serveurs principaux
Sous l’onglet Serveurs principaux, sélectionnez Ajouter un pool principal :
- Nom : entrez signalr pour le pool principal de ressources de SignalR Service.
- Cibles de back-end Cible : nom d’hôte de votre instance SignalR Service ASRS1, par exemple,
asrs1.service.signalr.net
- Sélectionnez Suivant : Configuration.
Sous l’onglet Configuration, dans la colonne Règles de routage, sélectionnez Ajouter une règle de routage :
Nom de la règle : myRoutingRule
Priorité : 1
Sous l’onglet Écouteur dans la fenêtre Ajouter une règle de routage, entrez les valeurs suivantes pour l’écouteur :
- Nom de l’écouteur : Entrez myListener comme nom pour l’écouteur.
- Adresse IP du front-end : Sélectionnez Publique pour choisir l’adresse IP publique que vous avez créée pour le front-end.
- Protocole: HTTP
- Dans cet article, nous utilisons le protocole frontal HTTP sur Application Gateway pour simplifier la démonstration et vous aider à commencer plus facilement. Mais en réalité, il se peut que vous deviez activer le protocole HTTPs et un Domaine client sur celui-ci avec un scénario de production.
- Acceptez les valeurs par défaut pour les autres paramètres sous l’onglet Écouteur
Sous l’onglet Cibles de back-end, utilisez les valeurs suivantes :
Type cible : pool principal.
Cible de back-end : sélectionnez sginalr créé précédemment.
Paramètres de back-end : sélectionnez Ajouter pour ajouter un nouveau paramètre.
- Nom des paramètres de back-end : mySetting.
- Protocole de back-end : HTTPS.
- Utiliser un certificat d’autorité de certification bien connue : Oui.
- Remplacer par le nouveau nom d’hôte : Oui
- Remplacement du nom d’hôte : Choisir le nom d’hôte à partir de la cible de back-end.
- Conservez les autres valeurs par défaut
Révise et crée l’AG1
Configurer une sonde d’intégrité d’Application Gateway
Une fois l’AG1 créée, dans la section Paramètres du portail, accédez à l’onglet Sondes d’intégrité, puis modifiez le chemin d’accès de la sonde d’intégrité en /api/health
Test rapide
Essayez avec une requête client non valide
https://asrs1.service.signalr.net/client
qui retourne l’erreur 400 avec le message Le paramètre de requête « hub » est obligatoire, indiquant que la requête est parvenue à SignalR Service et a été validée.curl -v https://asrs1.service.signalr.net/client
renvoie
< HTTP/1.1 400 Bad Request < ... < 'hub' query parameter is required.
Accédez à l’onglet Vue d’ensemble de l’AG1 et découvrez l’adresse IP publique du Serveur frontal
Visitez le point de terminaison de santé via l’AG1
http://<frontend-public-IP-address>/client
qui retourne également 400 avec le message d’erreur Le paramètre de requête « hub » est obligatoire. Cela signifie que la requête a atteint SignalR Service via Application Gateway avec succès et a validé la requête.curl -I http://<frontend-public-IP-address>/client
renvoie
< HTTP/1.1 400 Bad Request < ... < 'hub' query parameter is required.
Exécuter une conversation via Application Gateway
Désormais, le trafic peut atteindre SignalR Service via Application Gateway. Le client peut utiliser l’adresse IP publique d’Application Gateway ou le nom de domaine personnalisé pour accéder à la ressource. Utilisons cette application de conversation en guise d’exemple. Commençons par l’exécuter localement.
Des chaînes de connexion brutes sont utilisées dans cet article à des fins de démonstration uniquement. 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.
Obtenons d’abord la chaîne de connexion d’ASRS1
- Sous l’onglet Chaînes de connexion d’ASRS1
- Point de terminaison client : entrez l’URL utilisant l’adresse IP publique frontale d’AG1, par exemple,
http://20.88.8.8
. Il s’agit d’un générateur de chaîne de connexion intervenant lors de l’utilisation de proxys inverses, dont la valeur n’est pas conservée en vue d’un prochain accès à cet onglet. Une fois la valeur entrée, la chaîne de connexion ajoute une sectionClientEndpoint
. - Copiez la chaîne de connexion
- Point de terminaison client : entrez l’URL utilisant l’adresse IP publique frontale d’AG1, par exemple,
- Sous l’onglet Chaînes de connexion d’ASRS1
Cloner le dépôt GitHub https://github.com/aspnet/AzureSignalR-samples
Accédez au dossier samples/Chatroom :
Définissez la chaîne de connexion copiée et exécutez l’application localement. Vous pouvez voir la présence d’une section
ClientEndpoint
dans ConnectionString.cd samples/Chatroom dotnet restore dotnet user-secrets set Azure:SignalR:ConnectionString "<copied-connection-string-with-client-endpoint>" dotnet run
Ouvrez http://localhost:5000 à partir du navigateur et utilisez F12 pour afficher les traces. Vous pouvez voir que la connexion WebSocket est établie via AG1.
Sécuriser SignalR Service
Dans la section précédente, nous avons configuré SignalR Service en tant que service principal d’Application Gateway, et nous pouvons appeler SignalR Service directement à partir du réseau public ou via Application Gateway.
Dans cette section, nous allons configurer SignalR Service pour refuser tout trafic en provenance du réseau public et n’accepter que le trafic en provenance d’Application Gateway.
Configurer SignalR Service
Configurons SignalR Service pour n’autoriser que les accès privés. Pour plus d’informations, consultez Utiliser un point de terminaison privé pour SignalR Service.
Accédez à l’instance SignalR Service ASRS1 dans le portail.
Sous l’onglet Mise en réseau :
Sous l’onglet Accès public : modifiez Accès de réseau public en Désactivé, puis sélectionnez Enregistrer. Vous ne pouvez désormais plus accéder à SignalR Service à partir du réseau public.
Sous l’onglet Accès public, sélectionnez + Point de terminaison privé :
- Sous l’onglet Informations de base :
- Nom : PE1
- Nom de l’interface réseau : PE1-nic
- Région : veillez à choisir la même région que votre Application Gateway
- Sélectionnez Suivant : Ressources
- Sous l’onglet Ressources
- Conservez les valeurs par défaut
- Sélectionnez Suivant : réseau virtuel
- Sous l’onglet Réseau virtuel
- Réseau virtuel : sélectionnez VN1 créé précédemment
- Sous-réseau : Sélectionnez VN1/myBackendSubnet créé précédemment
- Conservez les autres paramètres par défaut
- Sélectionnez Suivant : DNS
- Sous l’onglet DNS
- Intégration avec zone DNS privée : Oui
- Examiner et créer le point de terminaison privé
- Sous l’onglet Informations de base :
Actualiser le pool principal d’Application Gateway
Étant donné qu’Application Gateway a été configuré avant qu’un point de terminaison privé soit disponible pour l’utiliser, nous devons actualiser le pool principal pour qu’il examine la zone DNS privée et comprenne qu’il doit acheminer le trafic vers le point de terminaison privé au lieu de l’adresse publique. Nous effectuons l’actualisation en définissant le nom de domaine complet (FQDN) principal sur une autre valeur, puis en le rétablissant.
Accédez à l’onglet Pools principaux pour AG1, puis sélectionnez signalr :
- Étape 1 : modifiez la cible
asrs1.service.signalr.net
en une autre valeur, par exemplex.service.signalr.net
, puis sélectionnez Enregistrer - Étape 2 : rétablir la cible sur
asrs1.service.signalr.net
Test rapide
Revisitons maintenant
https://asrs1.service.signalr.net/client
. Avec l’accès public désactivé, il retourne l’erreur 403 à la place.curl -v https://asrs1.service.signalr.net/client
renvoie
< HTTP/1.1 403 Forbidden
Visitez le point de terminaison via l’AG1
http://<frontend-public-IP-address>/client
qui retourne 400 avec le message d’erreur Le paramètre de requête « hub » est obligatoire. Cela signifie que la requête a atteint SignalR Service via Application Gateway.curl -I http://<frontend-public-IP-address>/client
renvoie
< HTTP/1.1 400 Bad Request < ... < 'hub' query parameter is required.
Maintenant, si vous réexécutez l’application de conversation localement, vous verrez des messages d’erreur Failed to connect to .... The server returned status code '403' when status code '101' was expected.
parce que l’accès public est désactivé, de sorte que les connexions de serveur localhost ne peuvent plus se connecter au service SignalR.
Déployons l’application de conversation dans le même réseau virtuel avec ASRS1 afin que la conversation puisse communiquer avec ASRS1.
Déployer l’application de conversation sur Azure
Sur le Portail Azure, recherchez App Services et sélectionnez Créer Application web.
Sous l’onglet Informations de base, utilisez ces valeurs pour les paramètres d’application web suivants :
- Abonnement, Groupe de ressources et Région : paramètres identiques à ceux choisis pour SignalR Service.
- Nom : WA1
- Publier : Code
- Pile d’exécution : .NET 6 (LTS)
- Système d’exploitation : Linux
- Région : assurez-vous qu’elle est identique à celle que vous choisissez pour SignalR Service
- Sélectionnez Suivant : Déploiement, conservez toutes les valeurs par défaut, puis sélectionnez Suivant : Mise en réseau
Sous l’onglet Mise en réseau
- Activer l’injection de réseau : sélectionnez Activée
- Réseau virtuel : sélectionnez VN1 créé précédemment
- Activer l’intégration au réseau virtuel : Activée
- Sous-réseau sortant : créer un sous-réseau
- Sélectionner Vérifier + créer
Nous allons maintenant déployer notre application de conversation sur Azure. Below
Nous utilisons Azure CLI pour déployer notre application de conversation sur Azure. Consultez Guide de démarrage rapide : Déployer une application web ASP.NET pour d’autres environnements de déploiement déployés sur Azure.
Dans le dossier samples/Chatroom, exécutez les commandes ci-dessous :
# Build and publish the assemblies to publish folder
dotnet publish --os linux -o publish
# zip the publish folder as app.zip
cd publish
zip -r app.zip .
# use az CLI to deploy app.zip to our webapp
az login
az account set -s <your-subscription-name-used-to-create-WA1>
az webapp deploy -g <resource-group-of-WA1> -n WA1 --src-path app.zip
Maintenant que l’application web est déployée, accédons au portail pour WA1 et effectuons les mises à jour suivantes :
Dans l’onglet Configuration :
Nouveaux paramètres de l’application :
Nom Valeur WEBSITE_DNS_SERVER 168.63.129.16 WEBSITE_VNET_ROUTE_ALL 1 Nouvelle chaîne de connexion
Nom Valeur Type AzureSignalRConnectionString Chaîne de connexion copiée avec la valeur ClientEndpoint Sélectionnez Personnalisé
Sous l’onglet Paramètres TLS/SSL :
- HTTPS uniquement : Désactivé. Pour simplifier la démonstration, nous avons utilisé le protocole frontal HTTP sur Application Gateway. Par conséquent, nous devons désactiver cette option pour éviter de modifier l’URL HTTP en HTTPs automatiquement.
Accédez à l’onglet Vue d’ensemble et obtenez l’URL de WA1.
Obtenez l’URL et remplacez le schéma https par http, par exemple,
http://wa1.azurewebsites.net
. Ouvrez l’URL dans le navigateur. Vous pouvez maintenant commencer à converser. Utilisez F12 pour ouvrir des traces réseau. Vous pouvez voir que la connexion SignalR est établie via l’AG1.Remarque
Parfois, vous devez désactiver la redirection https automatique du navigateur et le cache de navigateur pour empêcher que l’URL soit redirigée vers HTTPS automatiquement.
Étapes suivantes
Désormais, vous avez créé une application de conversation en temps réel avec SignalR Service, et utilisé Application Gateway pour protéger vos applications et configurer une sécurité de bout en bout. En savoir plus sur SignalR Service.