En esta página se describe cómo proteger tu aplicación con encabezados de IAP firmados. Cuando se configura, Identity-Aware Proxy (IAP) usa JSON Web Tokens (JWT) para garantizar que se autoricen las solicitudes a tu aplicación. Esto protege tu aplicación de los siguientes riesgos:
- Inhabilitaciones accidentales de IAP
- Firewalls mal configurados
- Accesos desde dentro del mismo proyecto
Para poder proteger debidamente tu aplicación, es necesario usar encabezados firmados con todo tipo de aplicaciones.
Opcionalmente, si tienes una aplicación que funciona en un entorno estándar de App Engine, puedes usar la API de usuarios.
Ten en cuenta que las verificaciones de estado de Compute Engine y GKE no incluyen encabezados de JWT y que IAP no controla estas verificaciones. Si tu verificación de estado muestra errores de acceso, asegúrate de que esté configurada correctamente en la consola de Google Cloud y de que la validación del encabezado JWT permita la ruta de verificación de estado. Para obtener más información, consulta cómo crear una excepción de verificación de estado.
Antes de comenzar
Para poder proteger tu aplicación con encabezados firmados, necesitarás los siguientes elementos:
- Una aplicación a la que quieras que se conecten los usuarios
- Una biblioteca de JWT de terceros para tu lenguaje que sea compatible con el algoritmo
ES256
Protege tu aplicación con encabezados de IAP
Para proteger tu aplicación con JWT de IAP, verifica el encabezado, la carga útil y la firma del JWT. El JWT se encuentra en el encabezado de la solicitud HTTP x-goog-iap-jwt-assertion
. Si un atacante omite IAP, puede falsificar los encabezados de identidad sin firmar de IAP, x-goog-authenticated-user-{email,id}
. JWT de IAP proporciona una alternativa más segura.
Los encabezados firmados proporcionan seguridad adicional en caso de que una persona omita IAP. Ten en cuenta que, si IAP está activo, este quita los encabezados x-goog-*
proporcionados por el cliente cuando la solicitud se procesa en su infraestructura de entrega.
Verifica el encabezado JWT
Comprueba que el encabezado JWT cumpla con las siguientes restricciones:
Reclamaciones del encabezado JWT | ||
---|---|---|
alg |
Algoritmo | ES256 |
kid |
ID de la clave | Debe corresponder a una de las claves públicas que aparecen en el archivo de claves de IAP, disponible en dos formatos diferentes: https://www.gstatic.com/iap/verify/public_key y https://www.gstatic.com/iap/verify/public_key-jwk |
Asegúrate de que el JWT esté firmado por la clave privada que corresponda a la reclamación kid
del token. Para ello, primero debes obtener la clave pública de uno de estos dos lugares:
https://www.gstatic.com/iap/verify/public_key
: Esta URL contiene un diccionario JSON que asigna las reclamacioneskid
a los valores de clave públicahttps://www.gstatic.com/iap/verify/public_key-jwk
: Esta URL contiene las claves públicas de IAP en formato JWK
Una vez que tengas la clave pública, utiliza una biblioteca de JWT para verificar la firma.
Verifica la carga útil de JWT
Comprueba que la carga útil de JWT cumpla con las siguientes restricciones:
Reclamaciones de la carga útil de JWT | ||
---|---|---|
exp |
Hora de vencimiento | Debe ser en el futuro. El tiempo se mide en segundos transcurridos desde la época UNIX, con una tolerancia de 30 segundos debida al sesgo. El ciclo de vida máximo de un token es de 10 minutos + 2 × el sesgo |
iat |
Hora de emisión | Debe ser en el pasado. El tiempo se mide en segundos transcurridos desde la época UNIX, con una tolerancia de 30 segundos debida al sesgo |
aud |
Público | Debe ser una string con los siguientes valores:
|
iss |
Emisor | Debe ser https://cloud.google.com/iap |
hd |
Dominio de cuenta | Si una cuenta pertenece a un dominio alojado, se proporciona la reclamación hd para distinguir el dominio al cual se asocia la cuenta |
google |
Reclamación de Google |
Si uno o más niveles de acceso se aplican a la solicitud, sus nombres se almacenan en el objeto JSON de la reclamación google bajo la clave access_levels como un arreglo de cadenas.
Cuando especificas una política de dispositivos y la organización tiene acceso a los datos del dispositivo, |
Puedes obtener los valores de la cadena aud
mencionada anteriormente si accedes a la consola de Google Cloud, o puedes usar la herramienta de línea de comandos de gcloud.
Para obtener los valores de cadena aud
de la consola de Google Cloud, ve a la configuración de Identity-Aware Proxy de tu proyecto, haz clic en Más junto al recurso del Balanceador de cargas y, luego, selecciona Público de JWT del encabezado firmado. El cuadro de diálogo JWT del encabezado firmado que aparece muestra la reclamación aud
del recurso seleccionado.
Si quieres usar la herramienta de línea de comandos de gcloud gcloud para obtener los valores de cadena aud
, deberás conocer el ID del proyecto. Puedes encontrar el ID del proyecto en la tarjeta Información del proyecto de la consola de Google Cloud y, luego, ejecutar los comandos especificados a continuación para cada valor.
Número de proyecto
Para ver el número del proyecto con la herramienta de línea de comandos de gcloud, ejecuta el siguiente comando:
gcloud projects describe PROJECT_ID
El comando muestra resultados como el siguiente:
createTime: '2016-10-13T16:44:28.170Z' lifecycleState: ACTIVE name: project_name parent: id: '433637338589' type: organization projectId: PROJECT_ID projectNumber: 'PROJECT_NUMBER'
ID de servicio
Para ver el ID del servicio con la herramienta de línea de comandos de gcloud, ejecuta el siguiente comando:
gcloud compute backend-services describe SERVICE_NAME --project=PROJECT_ID --global
El comando muestra resultados como el siguiente:
affinityCookieTtlSec: 0 backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: https://www.googleapis.com/compute/v1/projects/project_name/regions/us-central1/instanceGroups/my-group connectionDraining: drainingTimeoutSec: 0 creationTimestamp: '2017-04-03T14:01:35.687-07:00' description: '' enableCDN: false fingerprint: zaOnO4k56Cw= healthChecks: - https://www.googleapis.com/compute/v1/projects/project_name/global/httpsHealthChecks/my-hc id: 'SERVICE_ID' kind: compute#backendService loadBalancingScheme: EXTERNAL name: my-service port: 8443 portName: https protocol: HTTPS selfLink: https://www.googleapis.com/compute/v1/projects/project_name/global/backendServices/my-service sessionAffinity: NONE timeoutSec: 3610
Recupera la identidad del usuario
Si todas las verificaciones anteriores se realizaron correctamente, recupera la identidad del usuario. La carga útil del token de ID contiene la siguiente información sobre el usuario:
Identidad del usuario de la carga útil del token de ID | ||
---|---|---|
sub |
Asunto |
El identificador estable y único del usuario; usa este valor en lugar del encabezado x-goog-authenticated-user-id
|
email |
Correo electrónico del usuario | Dirección de correo electrónico del usuario
|
Este es un ejemplo de código para proteger una aplicación con encabezados de IAP firmados:
C#
Go
Java
Node.js
PHP
Python
Ruby
Prueba tu código de validación
Si visitas tu app con los parámetros de consulta secure_token_test
, IAP incluirá un JWT no válido. Usa esto para asegurarte de que la lógica de validación de JWT controle todos los casos de falla y para ver cómo se comporta tu aplicación cuando recibe un JWT no válido.
Crea una excepción de verificación de estado
Como se mencionó anteriormente, las verificaciones de estado de Compute Engine y GKE no usan encabezados JWT. Además, IAP no controla las verificaciones de estado. Por tanto, deberás configurar la verificación de estado y la aplicación para que permitan el acceso de las verificaciones de estado.
Configura la verificación de estado
Si aún no estableciste una ruta para tu verificación de estado, usa la consola de Google Cloud para establecer una ruta no confidencial para la verificación de estado. Asegúrate de que esta ruta de acceso no se comparta con ningún otro recurso.
- Ve a la página Verificaciones de estado de la consola de Google Cloud.
Ir a la página Verificaciones de estado - Haz clic en la verificación de estado que estés usando para tu aplicación, y, a continuación, haz clic en Editar.
- En Solicitar ruta de acceso, agrega el nombre de una ruta no confidencial. Esto permite especificar la ruta de URL que usa Google Cloud cuando envía solicitudes de verificación de estado.
Si se omite este paso, la solicitud de verificación de estado se envía a
/
. - Haz clic en Guardar.
Configura la validación de JWT
En el código que llama a la rutina de validación de JWT, agrega una condición que devuelve un estado HTTP 200 para la ruta de acceso de tu solicitud de verificación de estado. Por ejemplo:
if HttpRequest.path_info = '/HEALTH_CHECK_REQUEST_PATH' return HttpResponse(status=200) else VALIDATION_FUNCTION
JWT para identidades externas
Si usas IAP con identidades externas, IAP emitirá un JWT firmado en cada solicitud autenticada, tal como lo hace con las identidades de Google. Sin embargo, existen algunas diferencias.
Información del proveedor
Cuando usas identidades externas, la carga útil de JWT contendrá una reclamación llamada gcip
, que contiene información sobre el usuario, como la URL de su foto y correo electrónico, así como cualquier atributo adicional específico del proveedor.
El siguiente es un ejemplo de un JWT para un usuario que accedió con Facebook:
"gcip": '{
"auth_time": 1553219869,
"email": "facebook_user@gmail.com",
"email_verified": false,
"firebase": {
"identities": {
"email": [
"facebook_user@gmail.com"
],
"facebook.com": [
"1234567890"
]
},
"sign_in_provider": "facebook.com",
},
"name": "Facebook User",
"picture: "https://graph.facebook.com/1234567890/picture",
"sub": "gZG0yELPypZElTmAT9I55prjHg63"
}',
Los campos email
y sub
Si Identity Platform autenticó a un usuario, los campos email
y sub
del JWT tendrán como prefijo al emisor del token de Identity Platform y el ID de instancia utilizado (si existiera). Por ejemplo:
"email": "securetoken.google.com/PROJECT-ID/TENANT-ID:demo_user@gmail.com", "sub": "securetoken.google.com/PROJECT-ID/TENANT-ID:gZG0yELPypZElTmAT9I55prjHg63"
Controla el acceso con sign_in_attributes
IAM no es compatible con las identidades externas, pero puedes usar reclamaciones incorporadas en el campo sign_in_attributes
para controlar el acceso. Por ejemplo, considera que un usuario accedió con un proveedor de SAML:
{
"aud": "/projects/project_number/apps/my_project_id",
"gcip": '{
"auth_time": 1553219869,
"email": "demo_user@gmail.com",
"email_verified": true,
"firebase": {
"identities": {
"email": [
"demo_user@gmail.com"
],
"saml.myProvider": [
"demo_user@gmail.com"
]
},
"sign_in_attributes": {
"firstname": "John",
"group": "test group",
"role": "admin",
"lastname": "Doe"
},
"sign_in_provider": "saml.myProvider",
"tenant": "my_tenant_id"
},
"sub": "gZG0yELPypZElTmAT9I55prjHg63"
}',
"email": "securetoken.google.com/my_project_id/my_tenant_id:demo_user@gmail.com",
"exp": 1553220470,
"iat": 1553219870,
"iss": "https://cloud.google.com/iap",
"sub": "securetoken.google.com/my_project_id/my_tenant_id:gZG0yELPypZElTmAT9I55prjHg63"
}
Podrías agregar a tu aplicación lógica similar al código que se encuentra a continuación para restringir el acceso a los usuarios con una función válida:
const gcipClaims = JSON.parse(decodedIapJwtClaims.gcip);
if (gcipClaims &&
gcipClaims.firebase &&
gcipClaims.firebase.sign_in_attributes &&
gcipClaims.firebase.sign_in_attribute.role === 'admin') {
// Allow access to admin restricted resource.
} else {
// Block access.
}
Se puede acceder a atributos de usuario adicionales desde los proveedores de OIDC y SAML de Identity Platform mediante la reclamación anidada gcipClaims.gcip.firebase.sign_in_attributes
.
Limitaciones de tamaño de los reclamos de la IdP
Después de que un usuario accede con Identity Platform, los atributos del usuario adicionales se propagarán a la carga útil del token de ID sin estado de Identity Platform, que se pasará de forma segura a la IAP. Luego, el IAP emitirá su propia cookie opaca sin estado que también contiene los mismos reclamos. IAP generará el encabezado JWT firmado según el contenido de la cookie.
Como resultado, si se inicia una sesión con una gran cantidad de reclamos, es posible que supere el tamaño máximo permitido de cookies, que suele ser de alrededor de 4 KB en la mayoría de los navegadores. Esto hará que falle la operación de acceso.
Debes asegurarte de que solo se propaguen los reclamos necesarios en los atributos OIDC o SAML del IdP. Otra opción es usar funciones de bloqueo para filtrar los reclamos que no son necesarios para la verificación de autorización.
const gcipCloudFunctions = require('gcip-cloud-functions');
const authFunctions = new gcipCloudFunctions.Auth().functions();
// This function runs before any sign-in operation.
exports.beforeSignIn = authFunctions.beforeSignInHandler((user, context) => {
if (context.credential &&
context.credential.providerId === 'saml.my-provider') {
// Get the original claims.
const claims = context.credential.claims;
// Define this function to filter out the unnecessary claims.
claims.groups = keepNeededClaims(claims.groups);
// Return only the needed claims. The claims will be propagated to the token
// payload.
return {
sessionClaims: claims,
};
}
});