Gestione delle sessioni IAP

In questa pagina viene descritto come Identity-Aware Proxy (IAP) gestisce una richiesta con una sessione scaduta e come assicurarsi che le richieste di app AJAX e WebSocket vadano a buon fine.

Flusso della 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 usa questo cookie per verificare che l'utente abbia ancora effettuato l'accesso. IAP richiede all'utente di eseguire l'accesso prima di accedere 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 a Google dell'utente. In questo caso, IAP richiederà all'utente di eseguire nuovamente l'accesso solo in una delle seguenti situazioni:

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

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 annulla la validità della sessione.

IAP ricontrolla l'autorizzazione di Identity and Access Management (IAM) per tutte le richieste durante le sessioni valide. Gli aggiornamenti ai criteri di accesso IAM di un'app protetta con IAP potrebbero richiedere alcuni minuti prima di diventare effettivi.

Scadenza della sessione IAP

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

Per l'autenticazione programmatica, IAP rispetta l'affermazione exp nel JWT inviata nell'intestazione Autorizzazione.

Per il flusso di accesso a Identity Platform, la sessione IAP rimane valida fino a un'ora dopo l'uscita dell'utente.

Richieste WebSocket

IAP supporta solo WebSocket per le richieste iniziali e non controlla continuamente l'autorizzazione. Quando viene ricevuta una richiesta WebSocket, inizia con una richiesta Upgrade HTTP. IAP la valuta come una richiesta HTTP GET standard. Dopo che la richiesta è stata autorizzata, IAP la passa al server, aprendo una connessione permanente. Dopodiché, IAP non monitora le richieste né aggiorna la sessione.

Risposte della sessione scadute

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

Richieste non AJAX

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

Richieste AJAX

Chrome e altri browser stanno eliminando gradualmente i cookie di terze parti. I consigli per effettuare richieste AJAX in questa pagina non funzionano se i cookie di terze parti sono disattivati. Tuttavia, i consigli forniti continueranno a funzionare se l'origine e la destinazione delle richieste AJAX provengono dallo stesso sito.

Per istruzioni sulla gestione dei cookie di terze parti in Chrome, consulta l'articolo Eliminare, consentire e gestire i cookie in Chrome.

IAP si basa sui cookie per gestire le sessioni utente. Si basa inoltre 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 delle risorse tra origini (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 fuori banda. Tieni presente che, per una richiesta AJAX che invia una richiesta CORS da source_domain->target_domain, dove target_domain ospita l'applicazione protetta da IAP, deve essere stata stabilita una sessione sul target_domain. Non è possibile condividere i cookie tra source_domain e target_domain.

Dopo aver stabilito la sessione su target_domain, lo sviluppatore deve attivare l'invio delle credenziali nella richiesta. Per impostazione predefinita, i metodi JavaScript non associano cookie alle richieste. Per abilitare le credenziali nella richiesta, per le richieste inviate con un oggetto XMLHttpRequest è necessario impostare la proprietà withCredentials su true, mentre per le richieste inviate con Fetch API l'opzione credentials deve essere impostata su include o same-origin.

La guida seguente consiglia agli sviluppatori web di essere in grado 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 con codice di stato 302 anziché un codice di stato 401 alle richieste AJAX, è possibile aggiungere un'intestazione X-Requested-With con valore "XMLHttpRequest" alle richieste AJAX. Questo indica a IAP che la richiesta ha origine da JavaScript.

Gestione di una risposta AJAX 401 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 a livello di target_domain. Se la finestra viene mantenuta come aperta, continuerà ad aggiornare la sessione periodicamente, chiedendo l'input dell'utente secondo le necessità. Facoltativamente, l'utente può scegliere di chiudere la finestra e il gestore per lo stato HTTP 401 nel codice dello sviluppatore dovrebbe visualizzare di nuovo una finestra 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 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 del clic

Il codice campione riportato di seguito installa un gestore di clic 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;
  }
}