Gestione delle sessioni IAP

In questa pagina viene descritto in che modo Identity-Aware Proxy (IAP) gestisce una richiesta con una sessione scaduta e come assicurarsi che le richieste dell'app AJAX abbiano esito positivo.

Flusso di sessione IAP

Quando utilizza il flusso di accesso standard IAP, l'utente riceve un cookie di sessione che fa riferimento alla sua sessione di accesso di Google. IAP utilizza questo cookie per confermare che l'utente sia ancora connesso. IAP richiede all'utente di eseguire l'accesso prima di poter accedere a un'app protetta da IAP.

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

  • L'utente è uscito dal proprio account
  • Il suo account è stato sospeso
  • L'account richiede la reimpostazione della password

Se un utente è disconnesso, IAP rileva una modifica dello stato dell'Account Google entro un paio di minuti. Una volta rilevato, IAP annulla la sessione.

IAP controlla di nuovo l'autorizzazione IAM (Gestione di identità e accessi) per tutte le richieste durante le sessioni valide. Gli aggiornamenti a un criterio di accesso IAM di un'app protetta da IAP potrebbero richiedere alcuni minuti per diventare effettivi.

Scadenza sessione IAP

Per il flusso di accesso IAP degli Account Google, la sessione IAP è associata alla sessione di accesso Google sottostante e scade solo alla scadenza di tale sessione.

Per l'autenticazione programmatica, IAP rispetta la rivendicazione exp del 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 è ancora connesso, il reindirizzamento è trasparente.

Richieste AJAX

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

Per effettuare correttamente una richiesta CORS a un'applicazione protetta da IAP, è necessario stabilire una sessione IAP al di fuori della 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 protetta da IAP, deve essere stabilita una sessione su target_domain. Non è possibile 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 allegano 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 per le richieste inviate con l'oggetto Fetch API è necessaria l'opzione credentials impostata su include o same-origin.

La seguente guida suggerisce un pattern con cui gli sviluppatori web possono 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 alla perfezione. Se ricevi una risposta del codice di stato 302 anziché un codice di stato 401 alle richieste AJAX, puoi aggiungere un'intestazione X-Requested-With con valore "XMLHttpRequest" alle richieste AJAX. Questo indica all'IAP che la richiesta proviene da JavaScript.

Gestione di una risposta AJAX 401 HTTP

Per stabilire una sessione IAP dopo che l'applicazione riceve 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 come aperta, continuerà ad aggiornare la sessione periodicamente, chiedendo l'input dell'utente in base alle necessità. Facoltativamente, l'utente può scegliere di chiudere la finestra e il gestore per lo stato HTTP 401 nel codice sviluppatore dovrebbe visualizzare di nuovo una finestra popup per l'aggiornamento della sessione, come richiesto.

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 un link di aggiornamento alla sessione per l'utente:

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 che la sessione è stata aggiornata:

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