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 tokens web JSON (JWT) para asegurarse de que una solicitud a tu aplicación esté autorizada. De esta forma, tu aplicación estará protegida frente a los siguientes riesgos:
- La compra en la aplicación se ha inhabilitado por error.
- Cortafuegos mal configurados
- Acceder desde el proyecto.
Para proteger correctamente tu aplicación, debes usar encabezados firmados en todos los tipos de aplicaciones.
Si tienes una aplicación del entorno estándar de App Engine, puedes usar la API Users.
Ten en cuenta que las comprobaciones del estado de Compute Engine y GKE no incluyen encabezados JWT y que IAP no gestiona las comprobaciones del estado. Si la comprobación del estado devuelve errores de acceso, asegúrate de que esté configurada correctamente en la consola Google Cloud y de que la validación del encabezado JWT permita la ruta de comprobación del estado. Para obtener más información, consulta el artículo sobre cómo crear una excepción de comprobación de estado.
Antes de empezar
Para proteger tu aplicación con encabezados firmados, necesitarás lo siguiente:
- Una aplicación a la que quieres que se conecten los usuarios.
- Una biblioteca JWT de terceros para tu idioma que admita el algoritmo
ES256
.
Proteger una aplicación con encabezados de IAP
Para proteger tu aplicación con el 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 elude IAP, puede falsificar los encabezados de identidad sin firmar de IAP, x-goog-authenticated-user-{email,id}
. El JWT de IAP ofrece una alternativa más segura.
Los encabezados firmados proporcionan seguridad secundaria en caso de que alguien eluda IAP. Ten en cuenta que, cuando se activa la compra en la aplicación, se eliminan los encabezados x-goog-*
proporcionados por el cliente cuando la solicitud pasa por la infraestructura de servicio de la compra en la aplicación.
Verificar el encabezado JWT
Verifica que el encabezado del JWT cumpla las siguientes restricciones:
Reclamaciones de encabezado JWT | ||
---|---|---|
alg |
Algoritmo | ES256 |
kid |
ID de clave |
Debe corresponderse con una de las claves públicas que aparecen en el archivo de claves de compras en aplicaciones, que está disponible en dos formatos:
https://www.gstatic.com/iap/verify/public_key
y
https://www.gstatic.com/iap/verify/public_key-jwk .
|
Asegúrate de que el JWT se haya firmado con la clave privada que corresponde a la reclamación kid
del token. Para ello, primero obtén la clave pública de uno de estos dos sitios:
https://www.gstatic.com/iap/verify/public_key
. Esta URL contiene un diccionario JSON que asigna las reclamacioneskid
a los valores de clave pública.https://www.gstatic.com/iap/verify/public_key-jwk
. Esta URL contiene las claves públicas de las compras en aplicaciones en formato JWK.
Una vez que tengas la clave pública, usa una biblioteca JWT para verificar la firma.
Verificar la carga útil del JWT
Verifica que la carga útil del JWT cumpla las siguientes restricciones:
Reclamaciones de la carga útil de JWT | ||
---|---|---|
exp |
Plazo de vencimiento | Debe ser una fecha posterior a la actual. El tiempo se mide en segundos desde el inicio del registro de tiempo de UNIX. Espera 30 segundos para que se produzca la inclinación. El tiempo de vida máximo de un token es de 10 minutos más 2 veces la diferencia. |
iat |
Hora de emisión | Debe ser una fecha anterior a la actual. El tiempo se mide en segundos desde el inicio del registro de tiempo de UNIX. Espera 30 segundos para que se produzca la inclinación. |
aud |
Audiencia |
Debe ser una cadena con los siguientes valores:
|
iss |
Emisor |
Debe ser https://cloud.google.com/iap .
|
hd |
Dominio de la cuenta |
Si una cuenta pertenece a un dominio alojado, se proporciona la
reclamación hd para diferenciar el
dominio al que está asociada la cuenta.
|
google |
Reclamación de Google |
Si se aplican uno o varios niveles de acceso a la solicitud, sus nombres se almacenan en el objeto JSON de la reclamación google , en la clave access_levels , como una matriz de cadenas.
Cuando especificas una política de dispositivo y la organización tiene acceso a los datos del dispositivo, el |
Puedes obtener los valores de la cadena aud
mencionada anteriormente accediendo a la consolaGoogle Cloud o usando la herramienta de línea de comandos gcloud.
Para obtener valores de cadena aud
Google Cloud de la consola, vaya a la
configuración de Identity-Aware Proxy
de su proyecto, haga clic en Más junto al recurso de balanceador de carga y, a continuación,
seleccione Audiencia de JWT de encabezado firmado. En el cuadro de diálogo JWT de encabezado firmado que aparece, se muestra la reclamación aud
del recurso seleccionado.
Si quieres usar la herramienta de línea de comandos gcloud CLI para obtener los valores de cadena aud
, debes saber el ID del proyecto. Puedes encontrar el ID del proyecto en la tarjeta Google Cloud consola
Información del proyecto y, a continuación, ejecutar los comandos especificados a continuación para cada valor.
Número de proyecto
Para obtener el número de tu proyecto con la herramienta de línea de comandos gcloud, ejecuta el siguiente comando:
gcloud projects describe PROJECT_ID
El comando devuelve un resultado 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 obtener el ID de tu servicio con la herramienta de línea de comandos gcloud, ejecuta el siguiente comando:
gcloud compute backend-services describe SERVICE_NAME --project=PROJECT_ID --global
El comando devuelve un resultado 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
Recuperar la identidad del usuario
Si todas las verificaciones anteriores se realizan correctamente, recupera la identidad del usuario. La carga útil del token de ID contiene la siguiente información del usuario:
Identidad de usuario de la carga útil del token de ID | ||
---|---|---|
sub |
Asunto |
Identificador único y estable del usuario. Usa este valor en lugar del encabezado x-goog-authenticated-user-id .
|
email |
Correo del usuario | Dirección de correo del usuario.
|
Aquí tienes un ejemplo de código para proteger una aplicación con encabezados de compras en la aplicación firmados:
C#
Go
Java
Node.js
PHP
Python
Ruby
Probar el código de validación
Si visitas tu aplicación con los parámetros de consulta secure_token_test
,
IAP incluirá un JWT no válido. Úsalo para asegurarte de que tu lógica de validación de JWT gestione todos los casos de error y para ver cómo se comporta tu aplicación cuando recibe un JWT no válido.
Crear una excepción de comprobación del estado
Como se ha mencionado anteriormente, las comprobaciones de estado de Compute Engine y GKE no usan encabezados JWT, y IAP no gestiona las comprobaciones de estado. Tendrás que configurar la comprobación del estado y la aplicación para permitir el acceso a la comprobación del estado.
Configurar la comprobación del estado
Si aún no has definido una ruta para la comprobación del estado, usa la consolaGoogle Cloud para definir una ruta no sensible para la comprobación del estado. Asegúrate de que ningún otro recurso comparta esta ruta.
- Ve a la página Comprobaciones de estado de la consola. Google Cloud
Ve a la página Comprobaciones del estado. - Haz clic en la comprobación de estado que estés usando en tu aplicación y, a continuación, en Editar.
- En Ruta de solicitud, añade un nombre de ruta que no sea sensible. Especifica la ruta de URL que usa Google Cloud al enviar solicitudes de comprobación del estado.
Si se omite, la solicitud de comprobación del estado se envía a
/
. - Haz clic en Guardar.
Configurar la validación de JWT
En el código que llama a la rutina de validación de JWT, añade una condición para que se devuelva un estado HTTP 200 en la ruta de la solicitud de comprobación del estado. Por ejemplo:
if HttpRequest.path_info = '/HEALTH_CHECK_REQUEST_PATH' return HttpResponse(status=200) else VALIDATION_FUNCTION
JWTs para identidades externas
Si usas IAP con identidades externas, IAP seguirá emitiendo un JWT firmado en cada solicitud autenticada, al igual que con las identidades de Google. Sin embargo, hay algunas diferencias.
Información del proveedor
Cuando se usan identidades externas, la carga útil del JWT contendrá una reclamación llamada gcip
. Esta reclamación contiene información sobre el usuario, como su correo electrónico y la URL de la foto, así como cualquier atributo adicional específico del proveedor.
A continuación, se muestra un ejemplo de un JWT de un usuario que ha iniciado sesión 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"
}',
Campos email
y sub
Si Identity Platform autenticó a un usuario, los campos email
y sub
del JWT tendrán como prefijo el emisor del token de Identity Platform y el ID de cliente usado (si procede). Por ejemplo:
"email": "securetoken.google.com/PROJECT-ID/TENANT-ID:demo_user@gmail.com", "sub": "securetoken.google.com/PROJECT-ID/TENANT-ID:gZG0yELPypZElTmAT9I55prjHg63"
Controlar el acceso con sign_in_attributes
IAM no se puede usar con identidades externas, pero puedes usar las reclamaciones insertadas en el campo sign_in_attributes
para controlar el acceso. Por ejemplo, supongamos que un usuario ha iniciado sesión 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"
}
Puedes añadir a tu aplicación una lógica similar al código que se muestra a continuación para restringir el acceso a los usuarios que tengan un rol válido:
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 de proveedores SAML y OIDC de Identity Platform mediante la reclamación gcipClaims.gcip.firebase.sign_in_attributes
anidada.
Limitaciones de tamaño de las reclamaciones de IdP
Cuando un usuario inicia sesión con Identity Platform, los atributos de usuario adicionales se propagan a la carga útil del token de ID de Identity Platform sin estado, que se transfiere de forma segura a IAP. A continuación, IAP emitirá su propia cookie opaca sin estado, que también contiene las mismas reclamaciones. IAP generará el encabezado JWT firmado en función del contenido de la cookie.
Por lo tanto, si se inicia una sesión con un gran número de reclamaciones, es posible que se supere el tamaño máximo permitido de las cookies, que suele ser de unos 4 KB en la mayoría de los navegadores. Esto provocará que falle la operación de inicio de sesión.
Debe asegurarse de que solo se propaguen las reclamaciones necesarias en los atributos SAML u OIDC del proveedor de identidades. Otra opción es usar funciones de bloqueo para filtrar las reclamaciones que no sean necesarias para la comprobació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,
};
}
});