Gestione delle sessioni IAP

Questa pagina descrive in che modo Identity-Aware Proxy (IAP) gestisce una richiesta con una sessione scaduta e come assicurarsi che le richieste AJAX e WebSocket vadano a buon fine.

Flusso della sessione IAP

Quando utilizzi il flusso di accesso IAP standard, l'utente riceve un cookie di sessione che fa riferimento alla sessione di accesso Google. IAP utilizza questo cookie per confermare che l'utente ha ancora eseguito l'accesso. IAP richiede l'accesso di un utente 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 di Google dell'utente. In questo caso, IAP richiederà all'utente di accedere nuovamente in una delle seguenti situazioni:

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

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

IAP esegue nuovamente il controllo dell'autorizzazione 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 acquisti in-app 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 scade la sessione, indipendentemente dall'attestazione exp nel JWT inviato nell'intestazione di autorizzazione.

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

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

Richiesta di accesso per gli Account Google

Il valore di loginHint impostato tramite IapSettings deve corrispondere al dominio dell'utente che esegue l'accesso. Se questi valori non corrispondono, viene visualizzato il prompt di accesso se il cookie IAP viene cancellato o è scaduto.

Richieste WebSocket

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

Risposte alla sessione scaduta

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, questo reindirizzamento è trasparente.

Richieste AJAX

Chrome e altri browser stanno ritirando gradualmente i cookie di terze parti. I consigli per effettuare richieste AJAX in questa pagina non funzioneranno se i cookie di terze parti sono disattivati. Tuttavia, i suggerimenti forniti rimarranno funzionali 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, vedi 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'istituzione 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 IAP.

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 l'applicazione protetta da IAP, è necessario stabilire una sessione su 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 allegare 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 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 sessioneIAPp.

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é 401 alle richieste AJAX, è possibile aggiungere un'intestazione X-Requested-With con un valore "XMLHttpRequest" alle richieste AJAX. Indica a IAP che la richiesta ha origine da JavaScript.

Gestione di una risposta AJAX HTTP 401

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 la sessione IAP solo all'indirizzo target_domain. Se la finestra rimane aperta, la sessione verrà aggiornata periodicamente e verrà richiesto l&#3input utenteut dell'utente in base alle necessità. Se vuole, l'utente può scegliere di chiudere la finestra e il gestore dello stato HTTP 401 nel codice dello sviluppatore dovrebbe riaprire una finestra per l'aggiornamento della sessione, se necessario.

Passaggio 1: modifica il codice dell'app

Il seguente esempio mostra come modificare il codice dell'app per gestire il codice di stato HTTP 401 e fornire all'utente un link per l'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 codice campione riportato di seguito 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) {
    // Attempting to start a new session.
    // XMLHttpRequests is used by the server to identify AJAX requests
    fetch('/favicon.ico', {
          method: "GET",
          credentials: 'include',
          headers: {
              'X-Requested-With': 'XMLHttpRequest'
          }
    .then((response) => {
      // Checking if browser has a session for the requested app
      if (response.status === 401) {
        // No new session detected. Try to get a session again
        window.setTimeout(checkSessionRefresh, 500);
      } else {
        // Session retrieved.
        iapSessionRefreshWindow.close();
        iapSessionRefreshWindow = null;
      }
    })
    });
  } else {
    iapSessionRefreshWindow = null;
  }
}