Configuration des paramètres HTTP d'Application Gateway
La passerelle d’application route le trafic vers les serveurs back-end en utilisant la configuration que vous spécifiez ici. Après avoir créé un paramètre HTTP, vous devez l’associer à une ou plusieurs règles de routage des demandes.
Affinité basée sur les cookies
Azure Application Gateway utilise des cookies gérés par passerelle pour gérer les sessions utilisateur. Quand un utilisateur envoie la première demande à Application Gateway, il définit un cookie d’affinité dans la réponse avec une valeur de hachage qui contient les détails de la session, afin que les demandes suivantes incluant le cookie d’affinité soient routées vers le même serveur back-end pour conserver l’adhérence.
Cette fonctionnalité est pratique quand vous voulez conserver une session utilisateur sur le même serveur et quand l’état de session est enregistré localement sur le serveur pour une session utilisateur. Si l’application ne peut pas gérer l’affinité basée sur les cookies, vous ne pouvez pas utiliser cette fonctionnalité. Pour l’utiliser, assurez-vous que les clients prennent en charge les cookies.
Remarque
Certaines analyses de vulnérabilité peuvent signaler le cookie d’affinité Application Gateway, car les indicateurs Secure ou HttpOnly ne sont pas définis. Ces analyses ne tiennent pas compte du fait que les données du cookie sont générées à l’aide d’un hachage unidirectionnel. Le cookie ne contient pas d’informations utilisateur et est utilisé exclusivement pour le routage.
La mise à jour v80 du navigateur Chromium a imposé que les cookies HTTP sans attribut SameSite soient traités comme SameSite=Lax. Pour les requêtes CORS (Cross-Origin Resource Sharing), si le cookie doit être envoyé dans un contexte tiers, il doit utiliser les attributs SameSite=None; Secure et il doit être envoyé seulement via HTTPS. Dans le cas contraire, dans un scénario HTTP uniquement, le navigateur n’envoie pas les cookies dans le contexte tiers. L’objectif de cette mise à jour à partir de Chrome est d’améliorer la sécurité et d’éviter les attaques par falsification de requête intersites (CSRF).
Pour prendre en charge ce changement, à partir du 17 février 2020, Application Gateway (tous les types de références SKU) injecte un autre cookie appelé ApplicationGatewayAffinityCORS en plus du cookie ApplicationGatewayAffinity existant. Deux attributs supplémentaires (« SameSite=None; Secure ») ont été ajoutés au cookie ApplicationGatewayAffinityCORS de sorte que les sessions persistantes soient maintenues même pour les requêtes cross-origin.
Notez que le nom du cookie d’affinité par défaut est ApplicationGatewayAffinity et que vous pouvez changer ce nom. Si vous utilisez un nom de cookie d’affinité personnalisé, un cookie supplémentaire est ajouté avec le suffixe CORS. Par exemple, CustomCookieNameCORS.
Remarque
Si l’attribut SameSite=None est défini, le cookie doit obligatoirement contenir aussi l’indicateur Secure et être envoyé via HTTPS. Si l’affinité de session est exigée sur CORS, vous devez migrer votre charge de travail vers HTTPS. Reportez-vous à la documentation sur le déchargement TLS et le protocole TLS de bout en bout pour Application Gateway ici : Vue d’ensemble, Configurer une passerelle Application Gateway avec terminaison TLS à l’aide du portail Azure, Configurer le protocole TLS de bout en bout à l’aide d’Application Gateway avec le portail.
Vidage des connexions
Le drainage des connexions vous permet de supprimer correctement les membres d’un pool de back-ends pendant les mises à jour de service planifiées. Cela s’applique aux instances principales qui sont
- supprimées explicitement du pool backend,
- supprimées pendant les opérations de mise à l’échelle ou
- signalées comme défectueuses par les sondes d’intégrité.
Vous pouvez appliquer ce paramètre à tous les membres d’un pool de backend en activant le drainage des connexion dans les paramètres du backend. Cela garantit que toutes les instances de désinscription dans un pool principal ne reçoivent pas de nouvelles requêtes/connexions tout en conservant les connexions existantes jusqu’à la valeur de délai d’expiration configurée. Cela est également vrai pour les connexions WebSocket.
| Type de configuration | Valeur |
|---|---|
| Valeur par défaut quand le drainage de connexion n’est pas activé dans le paramètre du back-end | 30 secondes |
| Valeur définie par l’utilisateur quand le drainage de connexion est activé dans le paramètre du back-end | 1 à 3 600 secondes |
La seule exception concerne les demandes liées à la désinscription des instances en raison d’une affinité de session gérée par la passerelle et qui continueront d’être transmises par proxy aux instances de désinscription.
Protocol
Application Gateway prend en charge les protocoles HTTP et HTTPS pour router les requêtes vers les serveurs back-end. Si vous choisissez HTTP, le trafic vers les serveurs back-end n’est pas chiffré. Si des communications non chiffrées ne sont pas acceptables, sélectionnez HTTPS.
Ce paramètre combiné avec HTTPS dans l’écouteur prend en charge le chiffrement TLS de bout en bout. Celui-ci vous permet de transmettre en toute sécurité des données sensibles chiffrées au serveur back-end. Chaque serveur back-end du pool de back-ends pour lequel un chiffrement TLS de bout en bout est activé doit être configuré avec un certificat afin de sécuriser la communication.
Port
Ce paramètre spécifie le port où les serveurs back-end écoutent le trafic provenant de la passerelle applicative Application Gateway. Vous pouvez configurer des ports allant de 1 à 65535.
Certificat racine approuvé
Si vous sélectionnez HTTPS comme protocole back-end, la passerelle applicative nécessite un certificat racine approuvé pour faire confiance au pool de back-ends et activer le protocole SSL de bout en bout. Par défaut, l’option Utiliser le certificat d’autorité de certification connu est définie sur Non. Si vous prévoyez d’utiliser un certificat auto-signé ou un certificat signé par une autorité de certification interne, vous devez fournir à la passerelle applicative Application Gateway le certificat public correspondant que le pool de back-ends utilisera. Ce certificat doit être chargé directement dans la passerelle applicative au format .CER.
Si vous prévoyez d’appliquer un certificat sur le pool de back-ends signé par une autorité de certification publique approuvée, vous pouvez définir l’option Utiliser le certificat de l’autorité de certification connue sur Oui et ignorer le chargement d’un certificat public.
Délai d’expiration de la demande
Ce paramètre spécifie le nombre de secondes pendant lesquelles la passerelle applicative attend de recevoir une réponse du serveur back-end.
Remplacer le chemin back-end
Ce paramètre vous permet de configurer un chemin de transfert personnalisé facultatif à utiliser quand la demande est transférée au back-end. Toute partie du chemin entrant qui correspond au chemin personnalisé dans le champ Remplacer le chemin back-end est copiée dans le chemin transféré. Le tableau suivant montre comment agit cette fonctionnalité :
Quand le paramètre HTTP est attaché à une règle de routage des demandes de base :
Demande d’origine Remplacer le chemin back-end Demande transférée au back-end /home/ /override/ /override/home/ /home/secondhome/ /override/ /override/home/secondhome/ Quand le paramètre HTTP est attaché à une règle de routage des demandes basée sur un chemin :
Demande d’origine Règle de chemin Remplacer le chemin back-end Demande transférée au back-end /pathrule/home/ /pathrule* /override/ /override/home/ /pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /home/ /pathrule* /override/ /override/home/ /home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /pathrule/home/ /pathrule/home* /override/ /override/ /pathrule/home/secondhome/ /pathrule/home* /override/ /override/secondhome/ /pathrule/ /pathrule/ /override/ /override/
Utiliser une sonde personnalisée
Ce paramètre associe une sonde personnalisée à un paramètre HTTP. Vous pouvez associer une seule sonde personnalisée à un paramètre HTTP. Si vous n’associez pas explicitement une sonde personnalisée, la sonde par défaut est utilisée pour superviser l’intégrité du back-end. Nous vous recommandons de créer une sonde personnalisée pour mieux contrôler la supervision de l’intégrité de vos back-ends.
Remarque
La sonde personnalisée ne supervise pas l’intégrité du pool de back-ends, sauf si le paramètre HTTP correspondant est explicitement associé à un écouteur.
Configuration du nom d’hôte
Application Gateway permet à la connexion établie au back-end d’utiliser un nom d’hôte différent de celui utilisé par le client pour se connecter à Application Gateway. Même si cette configuration peut être utile dans certains cas, remplacer le nom d’hôte de sorte qu’il soit différent entre le client et la passerelle applicative et entre la passerelle applicative et la cible back-end est une opération délicate.
En production, il est recommandé de conserver le même nom d’hôte entre le client et la passerelle applicative et entre la passerelle applicative et la cible back-end. Cela évite les problèmes potentiels liés aux URL absolues, aux URL de redirection et aux cookies liés à l’hôte.
Avant de configurer Application Gateway autrement, prenez connaissance des conséquences possibles d’une telle configuration, qui sont abordées de façon plus détaillée dans le Centre des architectures : Conserver le nom d’hôte HTTP d’origine entre un proxy inverse et son application web de back-end
Un paramètre HTTP influence l’en-tête HTTP Host dont se sert Application Gateway pour se connecter au back-end sur deux plans :
- « Choisir un nom d’hôte à partir d’une adresse back-end »
- « Remplacement du nom d’hôte »
Choisir un nom d’hôte à partir d’une adresse back-end
Cette fonctionnalité définit dynamiquement l’en-tête de l’hôte dans la requête sur le nom d’hôte du pool de back-ends. Elle utilise une adresse IP ou un nom de domaine complet.
Cette fonctionnalité s’avère utile quand le nom de domaine du back end est différent du nom DNS de la passerelle d’application et que le back-end s’appuie sur un en-tête d’hôte spécifique pour se résoudre en point de terminaison correct.
Exemple : des services multilocataires en tant que back-end. Un service d’application est un service multilocataire qui utilise un espace partagé avec une seule adresse IP. Ainsi, un service d’application est uniquement accessible par le biais des noms d’hôte configurés dans les paramètres du domaine personnalisé.
Par défaut, le nom de domaine personnalisé est example.azurewebsites.net. Pour accéder à votre service d’application via une passerelle applicative en utilisant un nom d’hôte qui n’est pas explicitement inscrit dans le service d’application ou le nom de domaine complet de la passerelle applicative, vous pouvez remplacer le nom d’hôte dans la demande d’origine par celui du service d’application. Pour cela, activez le paramètre Choisir un nom d’hôte à partir d’une adresse back-end.
Pour un domaine personnalisé dont le nom DNS personnalisé existant est mappé au service d’application, il est déconseillé d’activer le paramètre Choisir un nom d’hôte à partir d’une adresse back-end.
Remarque
Il n’est pas nécessaire pour App Service Environment, qui est un déploiement dédié.
Remplacement du nom d’hôte
Cette fonctionnalité remplace l’en-tête de l’hôte dans la demande entrante sur la passerelle d’application par le nom d’hôte que vous spécifiez.
Par exemple, si www.contoso.com est spécifié dans le paramètre Nom d’hôte, la requête initiale *https://appgw.eastus.cloudapp.azure.com/path1 est remplacée par *https://www.contoso.com/path1 au moment du transfert de la requête vers le serveur back-end.