Cette page a été traduite par l'API Cloud Translation.

Gérer les sessions IAP

Cette page décrit la façon dont Identity-Aware Proxy (IAP) traite une requête avec une session expirée et explique comment s'assurer que les requêtes d'application AJAX et les requêtes WebSocket aboutissent.

Flux de session IAP

Dans le cas du flux de connexion IAP standard, l'utilisateur reçoit un cookie de session qui référence sa session de connexion Google. IAP se sert de ce cookie pour confirmer que l'utilisateur est toujours connecté. IAP exige d'un utilisateur qu'il se connecte avant d'accéder à une application qu'il sécurise.

Les sessions IAP sont régulièrement actualisées. Toutefois, si l'utilisateur se connecte à l'aide d'un compte Google, les sessions IAP sont également associées à la session de connexion Google. Dans ce cas, IAP exige uniquement que l'utilisateur se reconnecte dans l'une des situations suivantes :

L'utilisateur s'est déconnecté de son compte.
Son compte a été suspendu.
La réinitialisation du mot de passe associé au compte est requise.

Si un utilisateur est déconnecté, l'IAP détecte un changement d'état du compte Google en quelques minutes. Une fois celui-ci détecté, IAP invalide la session.

IAP revérifie l'autorisation Identity and Access Management (IAM) pour toutes les requêtes pendant les sessions valides. La prise en compte des mises à jour de la stratégie d'accès IAM d'une application sécurisée par IAP peut prendre quelques minutes.

Expiration de la session IAP

Pour un flux de connexion à l'aide d'un compte Google, la session IAP est liée à la session de connexion Google sous-jacente et n'expire qu'à l'expiration de cette session, quelle que soit la revendication exp dans le jeton JWT envoyé dans l'en-tête d'autorisation.

Pour l'authentification automatisée, IAP respecte la revendication exp dans le jeton JWT envoyée dans l'en-tête d'autorisation.

Pour le flux de connexion Identity Platform, la session IAP reste valide jusqu'à une heure après la déconnexion de l'utilisateur.

Requêtes WebSocket

L'IAP n'est compatible avec WebSocket que pour les requêtes initiales et ne vérifie pas l'autorisation en continu. Lorsqu'une requête WebSocket est reçue, elle commence par une requête HTTP Upgrade. L'IAP l'évalue comme une requête HTTP GET standard. Une fois la requête autorisée, l'IAP la transmet au serveur, ce qui ouvre une connexion persistante. Par la suite, l'IAP ne surveille pas les requêtes ni n'actualise la session.

Réponses pour les sessions expirées

IAP renvoie différentes réponses pour les sessions expirées en fonction du type de requête.

Requêtes non-AJAX

Pour les requêtes non-AJAX, l'utilisateur est redirigé vers le flux de connexion pour actualiser la session. Si l'utilisateur est toujours connecté, cette redirection est transparente.

Requêtes AJAX

Chrome et d'autres navigateurs abandonnent progressivement les cookies tiers. Les recommandations concernant l'exécution de requêtes AJAX sur cette page ne fonctionneront pas si les cookies tiers sont désactivés. Toutefois, les recommandations fournies restent fonctionnelles si la source et la cible des requêtes AJAX proviennent du même site.

Pour savoir comment gérer les cookies tiers dans Chrome, consultez Supprimer, autoriser et gérer les cookies dans Chrome.

IAP s'appuie sur les cookies pour gérer les sessions utilisateur. Il repose également sur une séquence de redirections pour établir une session dans le cadre d'un flux de connexion. L'établissement d'une session n'est pas toujours possible si l'application utilise Cross-Origin Resource Sharing (CORS) pour envoyer des requêtes AJAX à une application protégée par IAP.

Pour envoyer une requête CORS à une application protégée par IAP, une session IAP doit être établie hors bande. Notez que pour une requête AJAX qui envoie une requête CORS à partir de source_domain->target_domain où target_domain héberge l'application protégée par IAP, une session doit être établie sur le target_domain. Il n'existe aucun moyen de partager des cookies entre source_domain et target_domain.

Une fois la session sur target_domain établie, le développeur doit activer l'envoi des identifiants dans la requête. Par défaut, les méthodes JavaScript ne joignent pas les cookies aux requêtes. Pour activer les identifiants dans la requête, les requêtes envoyées avec un objet XMLHttpRequest doivent avoir la propriété withCredentials définie sur "true", alors que les requêtes envoyées avec la méthode Fetch API doivent avoir l'option credentials définie sur include ou same-origin.

Le guide suivant recommande un modèle permettant aux développeurs Web de créer et d'actualiser une session IAP.

Comprendre la réponse IAP

Pour les requêtes AJAX, IAP renvoie un code d'état HTTP 401: Unauthorized. Notez que la détection de requêtes AJAX ne peut pas être réalisée parfaitement. Si vous obtenez une réponse de code d'état 302 au lieu du code d'état 401 aux requêtes AJAX, un en-tête X-Requested-With possédant la valeur "XMLHttpRequest" peut être ajouté aux demandes AJAX. Cela indique à IAP que la requête provient de JavaScript.

Traiter une réponse AJAX HTTP `401`

Pour établir une session IAP après que l'application reçoit la requête HTTP 401, l'application peut ouvrir une nouvelle fenêtre pour l'URL target_domain + ?gcp-iap-mode=DO_SESSION_REFRESH. Il s'agit d'un gestionnaire spécial qui établit uniquement la session IAP sur target_domain. Si la fenêtre est conservée comme étant ouverte, elle continuera d'actualiser régulièrement la session et vous demandera l'entrée utilisateur, si nécessaire. L'utilisateur peut également choisir de fermer la fenêtre. Le gestionnaire de l'état HTTP 401 du code du développeur doit alors afficher à nouveau une fenêtre pour actualiser la session selon les besoins.

Étape 1 : Modifiez le code de l'application

L'exemple suivant montre comment modifier le code de votre application afin de gérer le code d'état HTTP 401 et de fournir un lien d'actualisation de session à l'utilisateur :

if (response.status === 401) {
  statusElm.innerHTML = 'Login stale. <input type="button" value="Refresh" onclick="sessionRefreshClicked();"/>';
}

Étape 2 : Installez un gestionnaire onclick

L'exemple de code ci-dessous permet d'installer un gestionnaire onclick qui ferme la fenêtre après l'actualisation de la session :

var iapSessionRefreshWindow = null;

function sessionRefreshClicked() {
  if (iapSessionRefreshWindow == null) {
    iapSessionRefreshWindow = window.open("/?gcp-iap-mode=DO_SESSION_REFRESH");
    window.setTimeout(checkSessionRefresh, 500);
  }
  return false;
}

function checkSessionRefresh() {
  if (iapSessionRefreshWindow != null && !iapSessionRefreshWindow.closed) {
    fetch('/favicon.ico').then(function(response) {
      if (response.status === 401) {
        window.setTimeout(checkSessionRefresh, 500);
      } else {
        iapSessionRefreshWindow.close();
        iapSessionRefreshWindow = null;
      }
    });
  } else {
    iapSessionRefreshWindow = null;
  }
}