Reautenticación de IAP

La reautenticación de IAP permite que los propietarios de servicios y aplicaciones o losGoogle Cloud administradores requieran que los usuarios finales autenticados se vuelvan a autenticar después de un período específico cuando accedan a un servicio o una aplicación protegidos por IAP, y limita el tiempo durante el que un usuario puede acceder a un servicio o una aplicación protegidos por IAP antes de que se requiera la autenticación.

La reautenticación de IAP (o reauth) está diseñada para aplicar políticas de reautenticación para servicios y aplicaciones (o apps) protegidos por IAP. Con este servicio, puedes aplicar políticas de reautenticación para servicios y aplicaciones críticos que manejan información confidencial. Por ejemplo, puedes especificar que los usuarios que accedan a una aplicación de RR.HH. crítica se vuelvan a autenticar cada hora con un segundo factor.

Métodos de reautenticación admitidos

Puedes usar los siguientes métodos para administrar la configuración de reautenticación:

• Acceso: Los usuarios finales se vuelven a autenticar con sus credenciales de acceso.
• Llave segura: Los usuarios finales se vuelven a autenticar con su llave de seguridad configurada.
• Métodos de dos factores inscritos: Los usuarios finales se vuelven a autenticar con uno de sus métodos de dos factores inscritos.

Para obtener más información, consulta IapSettings.

Cómo configurar una política de reautenticación

Los reauthSettings se incluyen como parte de IapSettings y se pueden establecer en cualquier tipo de recurso de la jerarquía de recursos. Puedes establecer reauthSettings a nivel de la organización, la carpeta, el proyecto o el servicio para aplicar restricciones. Por ejemplo, puedes limitar la duración de la sesión a un máximo de una hora para todas las aplicaciones de una organización o para una aplicación específica.

Existen dos tipos de políticas que puedes usar para configurar la reautenticación:

• Mínimo: Si el tipo de política se establece en MINIMUM en un recurso, como una organización, cuando se evalúan los parámetros de configuración de la reautenticación en el recurso de nivel inferior, como una carpeta, se combinan los dos parámetros de configuración. Si el recurso de nivel inferior no tiene parámetros de configuración de reautenticación, el resultado de la combinación son los parámetros de configuración no vacíos del recurso de nivel superior. De lo contrario, la combinación toma la duración de sesión más corta y el método de reautenticación de mayor precedencia entre los dos recursos. El tipo de política combinada resultante se establece en MINIMUM.

• Predeterminado: Si el tipo de política se establece como DEFAULT en un recurso, como una organización, cuando se evalúa el parámetro de configuración de reautenticación en el recurso de nivel inferior, como una carpeta, se usa el parámetro de configuración del recurso de nivel inferior si está configurado; de lo contrario, se aplica el parámetro de configuración de reautenticación del recurso de nivel superior.

Para ambos tipos de políticas, el proceso de evaluación se repite para determinar el reauthSettings del servicio o la aplicación objetivo. El reauthSettings efectivo en cualquier nivel se determina de la siguiente manera:

• Herencia: La configuración del recurso de nivel superior se combina con la del recurso de nivel inferior.

• Reglas de combinación: Si el recurso de nivel inferior no tiene parámetros de configuración de reautenticación específicos, hereda los parámetros de configuración del nivel superior.

  Si ambos niveles tienen reauthSettings, el resultado combinado usa lo siguiente:

  • Es la duración de sesión más corta.
  • Es el método de reautenticación con mayor precedencia.
  • La precedencia es Secure key (más alta), Enrolled second factors (media) y Login (más baja).

• Tipo de política resultante: El tipo de política de la configuración combinada es MINIMUM.

En los siguientes ejemplos, se muestran los parámetros de configuración antes y después de la evaluación. Durante la evaluación, se combinan la carpeta y la organización reauthSettings, lo que provoca que el tipo de política de la carpeta cambie a MINIMUM. Luego, la configuración combinada se usa para combinarla con el reauthSettings del servicio o la aplicación.

Organización IapSettings:

accessSettings:
  reauthSettings:
    method: "ENROLLED_SECOND_FACTORS"
    maxAge: "3600s"
    policyType: "MINIMUM"

Carpeta IapSettings:

accessSettings:
  reauthSettings:
    method: "LOGIN"
    maxAge: "1200s"
    policyType: "DEFAULT"

Servicio o aplicación IapSettings:

accessSettings:
  reauthSettings:
    method: "SECURE_KEY"
    maxAge: "7200s"
    policyType: "DEFAULT"

Configuración después de la combinación:

Organización IapSettings:

accessSettings:
  reauthSettings:
    method: "ENROLLED_SECOND_FACTORS"
    maxAge: "3600s"
    policyType: "MINIMUM"

Carpeta IapSettings:

accessSettings:
  reauthSettings:
    method: "ENROLLED_SECOND_FACTORS"
    maxAge: "1200s"
    policyType: "MINIMUM"

Servicio o aplicación IapSettings:

accessSettings:
  reauthSettings:
    method: "SECURE_KEY"
    maxAge: "1200s"
    policyType: "MINIMUM"

En este ejemplo, si el tipo de política de cada recurso se establece en DEFAULT, se usa el reauthSettings del servicio o la aplicación.

MaxAge

Usa el parámetro maxAge para especificar la frecuencia con la que un usuario final debe volver a autenticarse, indicado en segundos. Por ejemplo, para establecer una política de reautenticación de una hora, establece los segundos en 3600, como se muestra en el siguiente ejemplo:

accessSettings:
  reauthSettings:
    method: "LOGIN"
    maxAge: "3600s"
    policyType: "MINIMUM"

El valor mínimo para maxAge es de 300 segundos o cinco minutos.

Para establecer una política de reautenticación, completa los siguientes pasos.

gcloud iap settings set SETTING_FILE [--organization=ORGANIZATION --folder=FOLDER --project=/PROJECT --resource-type=RESOURCE_TYPE --service=SERVICE --version=VERSION

gcloud iap settings set SETTING_FILE --organization=ORGANIZATION

gcloud iap settings set SETTING_FILE --folder=FOLDER

gcloud iap settings set SETTING_FILE --project=PROJECT --resource-type=iap_web

gcloud iap settings set SETTING_FILE --project=PROJECT --resource-type=app-engine --service=SERVICE

accessSettings:
  reauthSettings:
    method: "LOGIN"
    maxAge: "3600s"
    policyType: "MINIMUM"

cat << EOF > iap_settings.json
{
  "access_settings": {
      "reauth_settings": {
            "method": "LOGIN",
            "maxAge": "300s",
            "policy_type": "DEFAULT"
        }
    }
}
EOF

gcloud iap settings get [--organization=ORGANIZATION --folder=FOLDER --project=/PROJECT --resource-type=RESOURCE_TYPE --service=SERVICE --version=VERSION]

curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d @iap_settings.json \
"https://iap.googleapis.com/v1/RESOURCE_NAME:iapSettings?updateMask=iapSettings.accessSettings.reauthSettings"

Información sobre las credenciales de reautenticación

Después de una autenticación exitosa, IAP crea una cookie en el navegador del usuario final. Para evitar la reautenticación frecuente de las aplicaciones en el mismo dominio, la cookie se establece en el dominio privado de nivel superior y es válida para todo ese dominio.

Por ejemplo, foo.example.com es un recurso protegido por IAP y tiene una política de reautenticación de IAP. Después de una autenticación exitosa, IAP establece una cookie en example.com, ya que ese es el dominio privado de nivel superior. Las aplicaciones del mismo dominio privado de nivel superior, como bar.example.com, usan las mismas credenciales de reautenticación y no le solicitan al usuario que se vuelva a autenticar siempre que las credenciales sean válidas.

Para las URLs como myapp.appspot.com, appspot.com es un dominio público, por lo tanto, el dominio privado de nivel superior es myapp.appspot.com.

Limitaciones conocidas

• La reautenticación solo se admite en los flujos de navegadores. No se admite el acceso programático a la cuenta de usuario. Por ejemplo, las aplicaciones para dispositivos móviles y computadoras de escritorio no pueden volver a autenticar a los usuarios porque los recursos que requieren reautenticación son inaccesibles para estas aplicaciones.
• IAP-TCP y las cuentas de servicio están exentos de los requisitos de reautenticación.
• La reautenticación no funciona con el tipo de miembro de Identity and Access Management allUsers.
• Las identidades externas, como OAuth y SAML, no son compatibles con la reautenticación.
• Las identidades de la federación de identidades de personal no son compatibles con la reautenticación de IAP.