Passerelle d'application

Voyez comment dépanner les problèmes courants liés à la passerelle d'application.

Le message d'erreur Ma réponse contient : 400 Demande incorrecte : valeur d'en-tête non valide

Découvrez la cause commune lorsqu'un message d'erreur de réponse contient : 400 Bad Request: invalid header value.

La passerelle d'application ajoute des en-têtes aux demandes qui sont mandatées par un serveur d'applications en amont. L'un de ces en-têtes, idcs_user_display_name, peut comporter des caractères non valides tels que définis par la demande de modification la plus récente, selon les valeurs définies pour le prénom et le nom de l'utilisateur du domaine d'identité. Cette nouvelle demande de modification limite les caractères autorisés aux caractères US-ASCII imprimables (c'est-à-dire 0x21 - 0x7E et les caractères d'espace et d'onglet horizontal). Voir Syntaxe et acheminement des messages HTTP/1.1 de la norme RFC 7230.

Les serveurs d'applications qui appliquent la nouvelle RFC rejetteront la demande avec la réponse : 400 Demande incorrecte : valeur d'en-tête non valide. Remarque : La réponse exacte dépend du serveur d'applications utilisé.

Supprimez les caractères non imprimables éventuels.

Le serveur de passerelle d'application ne reflète pas les modifications

Lorsque vous ne pouvez pas voir les modifications que vous avez apportées dans IAM sur le serveur de passerelle d'application, essayez ce qui suit.

Les modifications que vous apportez aux applications d'entreprise et aux définitions de passerelle d'application dans les domaines d'identité peuvent ne pas être prises en compte immédiatement dans la passerelle d'application car la passerelle d'application met en mémoire cache les informations sur les domaines d'identité, telles que les ressources, les politiques d'authentification et les valeurs d'en-tête des applications d'entreprise.

La passerelle d'application communique avec le service GIA à l'aide d'agents pour collecter les informations sur l'hôte et le port. Lorsque vous démarrez la passerelle d'application, son serveur NGINX est automatiquement configuré avec ces informations. Toutes les modifications apportées au service GIA sont périodiquement appliquées par les agents.

Par défaut, le délai d'actualisation de la politique et des en-têtes est de 3 600 secondes (1 heure). Pour modifier ces valeurs, connectez-vous au serveur de passerelle d'application et modifiez le fichier /usr/local/nginx/conf/cloudgate.config. Modifiez la valeur ttl pour policy et headers dans la section caching comme dans l'exemple suivant, puis redémarrez le serveur et l'agent de passerelle d'application.
"caching" : {
  "minimumTtl"            : 300,
  "headers"               : { "ttl": 3600 },
  "discovery"             : { "ttl": 3600 },
  "policy"                : { "ttl": 3600},
  "tenantKeys"            : { "ttl": 86400 }
}
Vous pouvez également modifier l'intervalle de scrutation des agents. Par défaut, le délai d'actualisation de l'agent pour obtenir la nouvelle configuration de la passerelle d'application à partir de GIA est de 60 secondes, soit le délai minimal pris en charge. Dans le fichier /usr/local/nginx/conf/cloudgate.config, modifiez la valeur pollIntervalSecs dans la section agentConfig comme dans l'exemple :
"agentConfig": {
    "pollIntervalSecs"    : 60,
    "daemon"         : true,
    "logLevel"        : "warn",
    "logFolder"        : "" 
}
Si vous souhaitez que les modifications de la configuration de l'application d'entreprise soient prises en compte immédiatement, arrêtez le serveur de passerelle d'application, puis démarrez le serveur.
/scratch/oracle/cloudgate/home/bin/cg-stop
/scratch/oracle/cloudgate/home/bin/cg-start
Si vous souhaitez que les modifications de la configuration de la passerelle d'application soient prises en compte immédiatement, arrêtez et redémarrez l'agent.
/scratch/oracle/cloudgate/home/bin/agent-stop
/scratch/oracle/cloudgate/home/bin/agent-start

Message Invalid_session

Lorsque la passerelle d'application ne peut pas communiquer correctement avec le service GIA, vous trouvez des messages invalid_session dans les fichiers journaux d'erreurs de la passerelle d'application.

Voici un exemple de messageinvalid_session dans le fichier error.log :

www-authenticate: Bearer error="invalid_session", error_description="Authentication Failure

Cela peut être dû à lamanière dont la passerelle d'application traite une demande client pour une ressource protégée. La passerelle d'application utilise des sous-demandes NGINX pour effectuer des demandes au service GIA, puis le résolveur Linux NGINX doit être configuré de manière appropriée pour permettre le bon fonctionnement de ces sous-demandes.

  1. Vérifiez que le paramètre de résolveur dans le fichier /usr/local/nginx/conf/nginx-cg-sub.conf est réglé à l'adresse IP correcte.
  2. Vérifiez que le nom du locataire dans le fichier /usr/local/nginx/conf/cloudgate.config est configuré correctement.

Erreur de commande GET 127.0.0.1 :53

Les fichiers journaux d'erreurs contiennent la commande GET 127.0.0.1 :53 en réponse à l'erreur numéro 500.

Comme la passerelle d'application envoie des sous-demandes à un servlet interne, la passerelle d'application nécessite que votre machine virtuelle écoute le port 53.

Le serveur de passerelle d'application doit communiquer avec lui-même au moyen de l'adresse IP 127.0.0.1 et du port 53.

Si vous exécutez la passerelle d'application dans un logiciel de machine virtuelle, configurez le réacheminement de port pour ce port de l'hôte à l'invité. Voir Configuration des règles de réacheminement de port.

Le serveur de passerelle d'application ne peut pas communiquer avec le service GIA

Lorsque votre serveur de passerelle A[[[] ne peut pas communiquer avec IAM, suivez ces étapes pour utiliser un client SSH tel que PuTTY et les données d'identification suivantes pour vous connecter au serveur de passerelle d'application.


  1. Exécutez la commande sudo su - pour vous connecter en tant que root et, lorsque vous y êtes invité, indiquez le mot de passe oracle.


  2. Installez telnet en exécutant la commande suivante :
    yum install telnet

  3. Exécutez la commande telnet suivante et essayez d'établir une connexion à votre instance GIA et à votre application à partir du serveur de passerelle d'application.
    telnet <idcs-tenant>.identity.oraclecloud.com 443

    Si telnet ne peut pas se connecter à votre instance GIA, communiquez avec l'administrateur de réseau pour appliquer une autre configuration de réseau afin de permettre au serveur de passerelle d'application d'établir la connexion avec votre instance GIA.

  4. Exécutez la commande exit pour vous déconnecter du compte racine.