Gestione delle sessioni IAP

In questa pagina viene spiegato in che modo Identity-Aware Proxy (IAP) gestisce una richiesta con una sessione scaduta e come assicurarsi che le richieste di app AJAX vengano completate.

Flusso di sessione IAP

Quando utilizza il flusso di accesso IAP standard, l'utente riceve un cookie di sessione che fa riferimento alla sua sessione di accesso a Google. IAP utilizza questo cookie per confermare che l'utente ha ancora eseguito l'accesso. IAP richiede l'accesso prima che l'utente acceda a un'app protetta da IAP.

Le sessioni IAP vengono aggiornate periodicamente. Tuttavia, se l'utente utilizza un Account Google per accedere, le sessioni IAP sono associate anche alla sessione di accesso di Google dell'utente. In questo caso, IAP richiederà all'utente di eseguire nuovamente l'accesso solo in una delle seguenti situazioni:

  • L'utente ha disconnesso il proprio account
  • Il suo account è stato sospeso
  • È necessario reimpostare la password dell'account

Se un utente non ha eseguito l'accesso, IAP rileva una modifica dello stato dell'Account Google entro un paio di minuti. Una volta rilevato, IAP invalida la sessione.

IAP ricontrolla l'autorizzazione di Identity and Access Management (IAM) per tutte le richieste durante le sessioni valide. L'applicazione degli aggiornamenti al criterio di accesso IAM di un'app protetta da IAP potrebbe richiedere alcuni minuti.

Scadenza della sessione IAP

Per un flusso di accesso che utilizza un Account Google, la sessione IAP è associata alla sessione di accesso Google sottostante e scade solo quando la sessione scade indipendentemente dalla rivendicazione exp nel JWT inviato nell'intestazione dell'autorizzazione.

Per l'autenticazione programmatica, IAP rispetta la rivendicazione exp nel JWT inviato nell'intestazione Authorization.

Per il flusso di accesso di Identity Platform, la sessione IAP rimane valida per un massimo di un'ora dopo la disconnessione dell'utente.

Risposte sessione scadute

IAP restituisce risposte diverse per le sessioni scadute in base al tipo di richiesta.

Richieste non AJAX

Per le richieste non AJAX, l'utente viene reindirizzato al flusso di accesso per aggiornare la sessione. Se l'utente ha ancora eseguito l'accesso, il reindirizzamento è trasparente.

Richieste AJAX

IAP utilizza i cookie per gestire le sessioni degli utenti. Si basa anche su una sequenza di reindirizzamenti per definire una sessione come parte di un flusso di accesso. Non è sempre possibile stabilire una sessione se l'applicazione utilizza la condivisione delle risorse tra origini (CORS) per inviare richieste AJAX a un'applicazione protetta da IAP.

Per effettuare correttamente una richiesta CORS a un'applicazione con protezione IAP, è necessario stabilire una sessione IAP fuori banda. Tieni presente che per una richiesta AJAX che invia una richiesta CORS da source_domain->target_domain in cui target_domain ospita l'applicazione con protezione IAP, deve essere stabilita una sessione su target_domain. Non c'è modo di condividere cookie tra source_domain e target_domain.

Una volta stabilita la sessione su target_domain, lo sviluppatore deve abilitare l'invio delle credenziali nella richiesta. Per impostazione predefinita, i metodi JavaScript non collegano i cookie alle richieste. Per abilitare le credenziali nella richiesta, le richieste inviate con un oggetto XMLHttpRequest devono avere la proprietà withCredentials impostata su true, mentre le richieste inviate con l'opzione Fetch API devono avere l'opzione credentials impostata su include o same-origin.

La seguente guida consiglia un pattern per consentire agli sviluppatori web di stabilire e aggiornare correttamente una sessione IAP.

Informazioni sulla risposta IAP

Per le richieste AJAX, IAP restituisce un codice di stato HTTP 401: Unauthorized. Tieni presente che il rilevamento delle richieste AJAX non può essere eseguito perfettamente. Se ricevi una risposta al codice di stato 302 anziché il codice di stato 401 alle richieste AJAX, puoi aggiungere alle richieste AJAX un'intestazione X-Requested-With con valore "XMLHttpRequest". Questo indica a IAP che la richiesta proviene da JavaScript.

Gestione di una risposta AJAX 401 di HTTP

Per stabilire una sessione IAP dopo che l'applicazione ha ricevuto HTTP 401, l'applicazione può aprire una nuova finestra per l'URL target_domain + ?gcp-iap-mode=DO_SESSION_REFRESH. Si tratta di un gestore speciale che stabilisce solo la sessione IAP all'indirizzo target_domain. Se la finestra viene mantenuta aperta, continuerà ad aggiornare la sessione periodicamente, chiedendo l'input dell'utente come richiesto. Facoltativamente, l'utente può scegliere di chiudere la finestra e il gestore per lo stato HTTP 401 nel codice dello sviluppatore dovrebbe mostrare nuovamente una finestra popup per l'aggiornamento della sessione, in base alle necessità.

Passaggio 1: modifica il codice dell'app

L'esempio seguente mostra come modificare il codice dell'app per gestire il codice di stato HTTP 401 e fornire all'utente un link di aggiornamento della sessione:

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

Il seguente codice di esempio installa un gestore onclick che chiude la finestra dopo l'aggiornamento della sessione:

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;
  }
}