Autorizzazione dell'utente
Panoramica
Le applicazioni Web che espongono contenuti privati richiedono meccanismi di controllo degli accessi per garantire che solo gli utenti autorizzati possano accedere ai contenuti. Gli esempi includono portali interni basati su SPA che richiedono l'autenticazione dell'utente e il download di file riservati. in base al caso d'uso, il controllo degli accessi può essere implementato a livello di origine o a livello di CDN.
Casi d'uso comuni
Autorizzazione basata sull'origine
Se utilizzi CloudFront come proxy inverso senza la memorizzazione nella cache abilitata (ad esempio, la cache disattivata è configurata in Policy gestita di caching), puoi semplicemente utilizzare le funzionalità di autorizzazione native della tua origine (ad esempio il Gateway API). Per fare in modo che funzioni correttamente, configura la Policy di richiesta origine per inoltrare all'origine l'attributo della richiesta contenente le informazioni di autorizzazione, come l'intestazione Autorizzazione.
Se i tuoi contenuti sono memorizzabili nella cache, ma preferisci continuare a gestire l'autorizzazione sulla tua infrastruttura, considera l'integrazione di CloudFront con i tuoi server di autorizzazione utilizzando Lambda@Edge. Questa architettura consente di sfruttare la memorizzazione nella cache di CloudFront. Scopri di più sulla sua implementazione in questo blog.
Considera le seguenti sezioni se desideri trasferire la logica di autorizzazione dai componenti della tua applicazione Web a CloudFront.
Autorizzazione basata su CloudFront utilizzando token firmati
CloudFront fornisce un meccanismo di autorizzazione nativo utilizzando URL o cookie firmati. Per utilizzare questo metodo, segui i passaggi illustrati nella documentazione:
- Configura una chiave crittografica asimmetrica per la firma dei token, utilizzando gruppi di chiavi di firma.
- Nel flusso di lavoro di autenticazione, aggiungi i campi token richiesti nei parametri di query o nei cookie dell'URL della risorsa proposta. Il token contiene una data di scadenza, l'ID della chiave di firma, la policy e una firma. La policy consente di definire le condizioni che devono essere soddisfatte da una richiesta di superamento del test di convalida del token da parte di CloudFront. Ad esempio, puoi utilizzare una policy personalizzata per generare un token valido per tutti gli URL che iniziano con un percorso specifico.
- Abilita la firma nel comportamento della cache di CloudFront utilizzato per i contenuti privati. Da quel momento in poi, tutte le richieste saranno controllate da CloudFront per la convalida dei token. Le richieste non autorizzate ricevono un errore 403, che può essere personalizzato utilizzando la funzionalità Pagina di errore personalizzata di CloudFront.
Usa aws-sdk per generare un token valido con la tua chiave privata. A titolo illustrativo, il codice seguente in Nodejs genera un URL firmato da CloudFront per un oggetto specifico edge-image.jpg valido per due ore.
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);L'output del frammento di codice precedente è simile al seguente:
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__
Autorizzazione basata su CloudFront tramite le Funzioni CloudFront
Se il token firmato nativo di CloudFront non soddisfa i requisiti di autorizzazione, puoi creare una logica di autorizzazione personalizzata utilizzando le funzioni edge. Ad esempio, potresti voler utilizzare una crittografia diversa per firmare token come la crittografia simmetrica, oppure potresti voler includere attributi non standard nella firma, come l'intestazione utente-agente, oppure potresti voler implementare una logica di tokenizzazione condizionale basata sulla rete di utenti. Le seguenti implementazioni personalizzate illustrano alcune delle possibilità offerte dalle funzioni edge:
- Funzioni CloudFront per convalidare il token basato su JWT. Tieni presente che, al momento, le Funzioni CloudFront non consentono chiamate di rete esterne e, di conseguenza, le chiavi di firma devono essere memorizzate nel codice della funzione. Per ridurre il rischio di memorizzare la chiave di firma nel codice della funzione CloudFront, non configurare manualmente la chiave nel codice, ma utilizza invece un'automazione che ruoti le chiavi e generi il codice della funzione prima della distribuzione su CloudFront. In questo modo, le chiavi non rischiano di essere caricate su repository pubblici come Github.
- Soluzione AWS: distribuzione sicura dei media a livello edge. Questa soluzione AWS utilizza la Funzione CloudFront per implementare un meccanismo di autorizzazione personalizzato adattato allo streaming video.
- Utilizzo di OpenID Connect per autenticare un'applicazione a pagina singola ospitata su S3. Le soluzioni utilizzano AWS Secrets Manager per archiviare le chiavi di firma e possono funzionare con un gestore dell’identità digitale esterno come Cognito o Okta. Questa implementazione è stata pubblicata prima del lancio delle Funzioni CloudFront, motivo per cui si basa completamente su Lambda@Edge. Inoltre, può essere ottimizzata per utilizzare le Funzioni CloudFront per la parte di autorizzazione e Lambda@Edge per l'integrazione con gli IDP.
