Autorización de usuarios
Información general
Las aplicaciones web que exponen contenido privado requieren mecanismos de control de acceso para garantizar que solo los usuarios autorizados puedan acceder al contenido. Algunos ejemplos son los portales internos basados en SPA que requieren la autenticación de los usuarios y la descarga de archivos confidenciales. El control de acceso se puede implementar en el nivel de origen o en el nivel de CDN según el caso de uso.
Casos de uso comunes
Autorización basada en el origen
Si usa CloudFront como proxy inverso sin el almacenamiento en caché habilitado (es decir, el almacenamiento en caché deshabilitado está configurado en la política de almacenamiento en caché administrada), puede usar simplemente las capacidades de autorización nativas de su origen (por ejemplo, API Gateway). Para que esto funcione correctamente, configura la política de la solicitud de origen para reenviar al origen el atributo de la solicitud que contiene la información de la autorización, como el encabezado de autorización.
Si el contenido se puede almacenar en caché, pero prefiere seguir administrando la autorización en su propia infraestructura, considere la posibilidad de integrar CloudFront con sus servidores de autorización mediante Lambda@Edge. Esta arquitectura le permite beneficiarse del almacenamiento en caché de CloudFront. Obtenga más información sobre esta implementación en este blog.
Tenga en cuenta las siguientes secciones si quiere transferir la lógica de autorización de los componentes de su aplicación web a CloudFront.
Autorización basada en CloudFront mediante tokens firmados
CloudFront proporciona un mecanismo de autorización nativo mediante URL firmadas o cookies firmadas. Para utilizar este método, siga los pasos que se explican en la documentación:
- Configure una clave criptográfica asimétrica para firmar los tokens mediante grupos de claves de firma.
- En su flujo de trabajo de autenticación, agregue los campos de tokens obligatorios en los parámetros de la consulta o las cookies de la URL del recurso a la venta. El token contiene una fecha de caducidad, el ID de la clave de firma, la política y una firma. La política le permite definir las condiciones que debe cumplir una solicitud para superar la prueba de validación de tokens de CloudFront. Por ejemplo, puede usar una política personalizada para generar un token que sea válido para todas las URL que comiencen por una ruta específica.
- Habilite la firma en el comportamiento de la caché de CloudFront que se usa para el contenido privado. A partir de ese momento, CloudFront controlará todas las solicitudes para la validación de tokens. Las solicitudes no autorizadas reciben un error 403, que se puede personalizar mediante la funcionalidad de la página de errores personalizados de CloudFront.
Utilice aws-sdk para generar un token válido con su clave privada. A modo de ejemplo, el siguiente código de Node.js genera una URL firmada de CloudFront para un objeto específico edge-image.jpg que es válida durante dos horas.
const AWS = require('aws-sdk');
// It's recommended not to store signing keys in code. The below is just an illustrative example.
const cloudfrontAccessKeyId = 'K25ULYFPSTHQP9';
const cloudFrontPrivateKey = '-----BEGIN RSA PRIVATE KEY-----\nMIIEowIBAAKCAQ....2gvvIH\n-----END RSA PRIVATE KEY-----';
const signer = new AWS.CloudFront.Signer(cloudfrontAccessKeyId, cloudFrontPrivateKey);
const signedUrl = signer.getSignedUrl({
url: 'https://d3jqlnxofenq2x.cloudfront.net/edge-image.jpg',
expires: Math.floor((Date.now() + 2 * 60 * 60 * 1000) / 1000),
});
console.log(signedUrl);La salida del fragmento de código anterior tiene este aspecto:
https://d3jqlnxofenq2x.cloudfront.net/edge-image.jpg?Expires=1660317158&Key-Pair-Id=K25ULYFP9THQP9&Signature=agW2XF9S5AW0YCc6c7pkCwccJmxaIAWFO~uXn9KtOXtz4JTY7eRF07opJiseGXJxzlMeD4V6FUH8I-gOH~Gvafa16RFV9IryxCyzL9mIYt-XbDKMrY0ONzTWUk2x16AKDK27VoUwEPiI9dpPXMp7f4MsrpKA-u6huZCsulh0~aAYN~x25uNoDO-WgZpfkKFeKc910u4PVnEaKLlZlpuJ0hqWUjMVPes9DfA~msToJeyjrVzLi2R8O8LuuYHsAMAHXr7E9qB8tAoDWz24CurCirxc6sB45Zc-oK9JigX0L4~F~F1TE9i39ysmQF4UrOyu0bp7MKGSDBwLE1P2C3gWNw__
Autorización basada en CloudFront mediante CloudFront Functions
Si el token firmado nativo de CloudFront no cumple con sus requisitos de autorización, puede crear una lógica de autorización personalizada mediante funciones de periferia. Por ejemplo, es posible que desee utilizar una criptografía diferente para firmar los tokens (como la criptografía simétrica), incluir atributos no estándar en la firma (como el encabezado de agente de usuario) o implementar una lógica de tokenización condicional basada en la red de usuarios. Las siguientes implementaciones personalizadas sirven para ilustrar algunas de las posibilidades de las funciones de periferia:
- CloudFront Functions para validar el token basado en JWT. Tenga en cuenta que CloudFront Functions actualmente no permite llamadas de red externas y, en consecuencia, las claves de firma deben almacenarse en el código de la función. Para reducir el riesgo de almacenar la clave de firma en el código de CloudFront Functions, no debe configurar manualmente la clave en el código, sino que debe utilizar una automatización que rote las claves y genere el código de la función antes de implementarla en CloudFront. De esta forma, las claves no corren el riesgo de cargarse en repositorios públicos como GitHub.
- Solución de AWS: entrega segura de contenido multimedia en la periferia. Esta solución de AWS utiliza CloudFront Functions para implementar un mecanismo de autorización personalizado adaptado al streaming de video.
- Uso de OpenID Connect para autenticar una aplicación de una sola página alojada en S3. Las soluciones utilizan AWS Secrets Manager para almacenar las claves de firma y pueden funcionar con un proveedor de identidades (IdP) externo, como Cognito u Okta. Esta implementación se publicó antes del lanzamiento de CloudFront Functions y por ello se basa totalmente en Lambda@Edge. Se puede optimizar para usar CloudFront Functions para la parte de autorización y Lambda@Edge para la integración con los IdP.
