Se usó la API de Cloud Translation para traducir esta página.

Administra las sesiones de IAP

En esta página, se describe cómo Identity-Aware Proxy (IAP) controla una solicitud con una sesión vencida y cómo asegurarse de que las solicitudes de aplicaciones AJAX y WebSocket se ejecuten correctamente.

Flujo de sesión de IAP

Cuando se usa el flujo de acceso estándar de IAP, el usuario recibe una cookie de sesión que hace referencia a su sesión de acceso de Google. IAP usa esta cookie para confirmar que el usuario aún está conectado. IAP requiere que el usuario acceda antes de ingresar a una aplicación protegida con IAP.

Las sesiones de IAP se actualizan de forma periódica. Sin embargo, si el usuario usa una Cuenta de Google para acceder, las sesiones de IAP también están vinculadas a la sesión de acceso de Google del usuario. En este caso, IAP solo requerirá que el usuario vuelva a acceder en una de las siguientes situaciones:

El usuario salió de su cuenta.
La cuenta se suspendió.
La cuenta requiere Restablecer la contraseña.

Si un usuario sale de la cuenta, IAP detecta un cambio en el estado de la Cuenta de Google tras un par de minutos. Una vez detectado, IAP invalida la sesión.

IAP vuelve a verificar la autorización de la administración de identidades y accesos (IAM) para todas las solicitudes durante las sesiones válidas. Las actualizaciones a la política de acceso de IAM de una aplicación protegida con IAP pueden tardar unos minutos en aplicarse.

Vencimiento de la sesión de IAP

Para un flujo de acceso con una Cuenta de Google, la sesión de IAP está vinculada a la sesión de acceso subyacente de Google y solo vence cuando esa sesión vence, independientemente del reclamo exp en el JWT que se envía en el encabezado de autorización.

Para la autenticación programática, IAP respeta la reclamación exp en el JWT enviado en el encabezado de la autorización.

Para el flujo de acceso de Identity Platform, la sesión de IAP es válida hasta una hora después de que el usuario cierra sesión.

Solicitudes de WebSocket

IAP solo admite WebSocket para las solicitudes iniciales y no verifica la autorización de forma continua. Cuando se recibe una solicitud de WebSocket, comienza con una solicitud HTTP Upgrade. IAP lo evalúa como una solicitud GET HTTP estándar. Después de que se autoriza la solicitud, el IAP la pasa al servidor y abre una conexión persistente. Después de esto, el IAP no supervisa las solicitudes ni actualiza la sesión.

Respuestas de sesión vencidas

IAP muestra respuestas diferentes para las sesiones vencidas según el tipo de solicitud.

Solicitudes no AJAX

En el caso de solicitudes que no son AJAX, se redirecciona al usuario al flujo de acceso para actualizar la sesión. Si el usuario todavía está conectado, este redireccionamiento es transparente.

Solicitudes AJAX

Chrome y otros navegadores eliminan las cookies de terceros. Las recomendaciones para realizar solicitudes AJAX en esta página no funcionarán si las cookies de terceros están inhabilitadas. Sin embargo, las recomendaciones proporcionadas seguirán siendo funcionales si la fuente y el destino de las solicitudes AJAX provienen del mismo sitio.

Para obtener instrucciones sobre cómo administrar cookies de terceros en Chrome, consulta Borra, permite y administra cookies en Chrome.

IAP se basa en cookies para administrar sesiones de usuario. También se basa en una secuencia de redireccionamientos para establecer una sesión como parte de un flujo de acceso. Establecer una sesión no siempre es posible si la aplicación utiliza el uso compartido de recursos entre dominios (CORS) para realizar solicitudes AJAX en una aplicación protegida con IAP.

Para realizar correctamente una solicitud CORS a una aplicación protegida con IAP, se debe establecer una sesión IAP. Ten en cuenta que, para una solicitud AJAX que envía una solicitud CORS desde source_domain->target_domain, en la que target_domain aloja la aplicación protegida con IAP, debe haber una sesión establecida en target_domain. No hay forma de compartir cookies entre source_domain y target_domain.

Una vez que se establece la sesión en target_domain, el desarrollador debe permitir que se envíen credenciales en la solicitud. Según la configuración predeterminada, los métodos de JavaScript no adjuntan cookies a las solicitudes. Para habilitar las credenciales en la solicitud, las solicitudes enviadas con un objeto XMLHttpRequest necesitan que la propiedad withCredentials esté configurada como verdadera, mientras que las solicitudes enviadas con la Fetch API necesita la opción credentials configurada en include o same-origin.

En la siguiente guía, se recomienda un patrón para que los desarrolladores web puedan establecer y actualizar una sesión de IAP de forma correcta.

Información sobre la respuesta de IAP

Para las solicitudes AJAX, IAP muestra un código de estado HTTP 401: Unauthorized. Ten en cuenta que las detecciones de las solicitudes de AJAX no son perfectas. Si obtienes una respuesta de un código de estado 302 en lugar de un código de estado 401 a solicitudes AJAX, se puede agregar un encabezado X-Requested-With con un valor de "XMLHttpRequest" a las solicitudes AJAX. Esto le indica a IAP que la solicitud se origina desde JavaScript.

Controla una respuesta AJAX HTTP `401`

Para establecer una sesión IAP después de que la aplicación reciba HTTP 401, la aplicación puede abrir una ventana nueva para la URL target_domain + ?gcp-iap-mode=DO_SESSION_REFRESH. Este es un controlador especial que solo establece la sesión de IAP en target_domain. Si la ventana se mantiene abierta, se mantendrá en la actualización continua de la sesión y se solicitará la entrada del usuario según sea necesario. De forma opcional, el usuario puede elegir cerrar la ventana y el controlador del estado HTTP 401 en el código del desarrollador debe mostrar nuevamente una ventana para la actualización de la sesión según sea necesario.

Paso 1: Modificar el código de tu aplicación

El siguiente ejemplo muestra cómo modificar el código de tu app para controlar el código de estado HTTP 401 y proporcionar un vínculo de actualización de sesión al usuario.

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

Paso 2: Instalar un controlador onclick

El código de muestra que aparece a continuación instala un controlador onclick que cierra la ventana después de que se actualiza la sesión.

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