Gestione delle sessioni IAP

Questa pagina descrive in che modo Identity-Aware Proxy (IAP) gestisce un con una sessione scaduta e come assicurarsi che l'applicazione AJAX e richieste WebSocket hanno esito positivo.

Flusso della sessione IAP

Quando si 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 all'utente di eseguire l'accesso prima di poter accedere a una app protetta da IAP.

Le sessioni IAP vengono aggiornate periodicamente. Tuttavia, se utente utilizza un account Google per accedere, le sessioni IAP sono legate anche alla piattaforma Google sessione di accesso. In questo caso, IAP richiederà solo all'utente di eseguire nuovamente l'accesso 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 non ha eseguito l'accesso, IAP rileva una variazione 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. Aggiornamenti a un Criterio di accesso IAM dell'app con protezione IAP potrebbero essere necessari alcuni minuti prima che le modifiche diventino effettive.

Scadenza della sessione IAP

Per un flusso di accesso che utilizza un Account Google, la sessione IAP è collegata alla sessione di accesso a Google sottostante e scade solo quando questa sessione scade, indipendentemente dal claim exp nel JWT inviato nell'intestazione di autorizzazione.

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

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

Richieste WebSocket

IAP supporta solo WebSocket per le richieste iniziali e non di controllare continuamente l'autorizzazione. Quando viene ricevuta una richiesta WebSocket, inizia con una richiesta HTTP Upgrade. IAP la valuta come richiesta HTTP GET standard. Una volta autorizzata, la richiesta viene passata dal sistema IAP al server, aprendo una connessione persistente. Dopodiché, IAP non monitora le richieste né aggiorna la sessione.

Risposte di 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, questo reindirizzamento viene sono trasparenti.

Richieste AJAX

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

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

IAP si basa sui cookie per gestire le sessioni utente. Inoltre, si basa su una sequenza di reindirizzamenti per stabilire una sessione nell'ambito di un flusso di accesso. L'impostazione di una sessione non è sempre possibile se l'applicazione utilizza la condivisione delle risorse tra origini (CORS) per effettuare richieste AJAX a un'applicazione protetta da acquisti in-app.

Per effettuare correttamente una richiesta CORS a un'applicazione protetta da IAP, è necessario stabilire una sessione IAP out-of-band. Tieni presente che per una richiesta AJAX che invia una richiesta CORS da source_domain->target_domain dove target_domain ospita un'applicazione protetta da IAP, deve esserci una sessione stabilito in data target_domain. Non è possibile condividere i cookie tra source_domain e target_domain.

Una volta stabilita 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 attivare le credenziali nella richiesta, le richieste inviate con un oggetto XMLHttpRequest devono avere la proprietà withCredentials impostata su true, mentre le richieste inviate con Fetch API devono avere l'opzione credentials impostata su include o same-origin.

La guida riportata di seguito 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 URL HTTP 401: Unauthorized codice di stato. Tieni presente che il rilevamento delle richieste AJAX non può essere eseguito perfettamente. Se ricevi una risposta con codice di stato 302 anziché 401 alle richieste AJAX, puoi aggiungere un'intestazione X-Requested-With con un valore di "XMLHttpRequest" alle richieste AJAX. Questo indica a IAP che la richiesta proviene da JavaScript.

Gestione di una risposta AJAX HTTP 401

Per stabilire una sessione IAP dopo che l'applicazione riceve401 HTTP, l'applicazione può aprire una nuova finestra per l'URLtarget_domain + ?gcp-iap-mode=DO_SESSION_REFRESH. Si tratta di un gestore speciale che stabilisce la sessione IAP solo in target_domain. Se la finestra viene mantenuto aperto, continuerà ad aggiornare periodicamente la sessione, chiedendo per input utente, come richiesto. Facoltativamente, l'utente può scegliere di chiudere la finestra e il gestore Lo stato HTTP 401 nel codice dello sviluppatore dovrebbe far apparire di nuovo una finestra per aggiornare la sessione in base alle esigenze.

Passaggio 1: modifica il codice dell'app

L'esempio seguente mostra come modificare il codice dell'app per gestire Codice di stato HTTP 401 e fornisci 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 src

Il codice campione riportato di seguito installa un gestore clic che chiude la finestra dopo la sessione viene 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;
  }
}