In questa pagina viene descritto come proteggere la tua app con intestazioni IAP firmate. Se configurato, Identity-Aware Proxy (IAP) utilizza token JWT (JSON Web Token) per garantire che una richiesta alla tua app sia autorizzata. In questo modo, la tua app è protetta dai seguenti tipi di rischi:
- IAP è stato disattivato per errore;
- Firewall non configurati correttamente;
- Accesso dall'interno del progetto.
Per proteggere correttamente la tua app, devi utilizzare le intestazioni firmate per tutti i tipi di app.
In alternativa, se hai un'app nell'ambiente standard di App Engine, è possibile utilizzare l'API Users.
Tieni presente che i controlli di integrità di Compute Engine e GKE non includono le intestazioni JWT e IAP non gestisce i controlli di integrità. Se il controllo di integrità restituisce errori di accesso, assicurati di averlo configurato correttamente nella console Google Cloud e che la convalida dell'intestazione JWT consenta il percorso del controllo di integrità. Per maggiori informazioni, consulta Creare un'eccezione del controllo di integrità.
Prima di iniziare
Per proteggere la tua app con le intestazioni firmate, è necessario quanto segue:
- Un'applicazione a cui vuoi che gli utenti si connettano.
- Una libreria JWT di terze parti per la tua lingua che supporti
l'algoritmo
ES256
.
Protezione dell'app con le intestazioni IAP
Per proteggere l'app con il JWT IAP, verifica l'intestazione, il payload e la firma del JWT. Il JWT si trova nell'intestazione della richiesta HTTP x-goog-iap-jwt-assertion
. Se un utente malintenzionato aggira IAP, può falsificare le intestazioni di identità non firmate IAP,
x-goog-authenticated-user-{email,id}
. Il JWT IAP offre
un'alternativa più sicura.
Le intestazioni firmate offrono sicurezza secondaria nel caso in cui qualcuno aggiri IAP. Tieni presente che, quando IAP è attivato, rimuove le intestazioni x-goog-*
fornite dal client quando la richiesta passa attraverso l'infrastruttura di pubblicazione IAP.
Verifica dell'intestazione JWT
Verifica che l'intestazione JWT sia conforme ai seguenti vincoli:
Attestazioni intestazioni JWT | ||
---|---|---|
alg |
Algoritmo | ES256 |
kid |
ID chiave |
Deve corrispondere a una delle chiavi pubbliche elencate nel file delle chiavi IAP, disponibile in due diversi formati: https://www.gstatic.com/iap/verify/public_key e https://www.gstatic.com/iap/verify/public_key-jwk .
|
Assicurati che il JWT sia stato firmato dalla chiave privata corrispondente
all'attestazione kid
del token. Per farlo, recupera la chiave pubblica da una di queste due posizioni:
https://www.gstatic.com/iap/verify/public_key
. Questo URL contiene un dizionario JSON che mappa le attestazionikid
alle coppie chiave pubblica.https://www.gstatic.com/iap/verify/public_key-jwk
. Questo URL contiene le chiavi pubbliche IAP in formato JWK.
Una volta ottenuta la chiave pubblica, utilizza una libreria JWT per verificare la firma.
Verifica del payload JWT
Verifica che il payload del JWT sia conforme ai seguenti vincoli:
Attestazioni di payload JWT | ||
---|---|---|
exp |
Scadenza | Deve essere nel futuro. Il tempo viene misurato in secondi dall'epoca di UNIX. Attendi 30 secondi per il disallineamento. La durata massima di un token è 10 minuti + 2 * disallineamento. |
iat |
Data di emissione | Deve essere nel passato. Il tempo viene misurato in secondi dall'epoca di UNIX. Attendi 30 secondi per il disallineamento. |
aud |
Pubblico |
Deve essere una stringa con i seguenti valori:
|
iss |
Emittente |
Deve essere https://cloud.google.com/iap .
|
hd |
Dominio dell'account |
Se un account appartiene a un dominio ospitato, viene fornita la rivendicazione hd per distinguere il dominio a cui è associato l'account.
|
google |
rivendicazione di Google |
Se uno o più livelli di accesso
si applicano alla richiesta, i loro nomi vengono archiviati all'interno dell'oggetto JSON della richiesta
google , nella chiave access_levels , sotto forma di array
di stringhe.
Quando specifichi un criterio relativo ai dispositivi e l'organizzazione ha accesso ai dati del dispositivo, il valore |
Puoi ottenere i valori della stringa aud
sopra menzionata accedendo alla console Google Cloud oppure utilizzando lo strumento a riga di comando gcloud.
Per ottenere i valori stringa aud
dalla console Google Cloud, vai alle impostazioni di Identity-Aware Proxy per il tuo progetto, fai clic su Altro accanto alla risorsa Bilanciatore del carico, quindi seleziona Pubblico JWT con intestazione firmata. La finestra di dialogo JWT con intestazione firmata visualizzata mostra la dichiarazione aud
per la risorsa selezionata.
Se vuoi utilizzare lo strumento a riga di comando gcloud gcloud CLI per ottenere i valori della stringa aud
, devi conoscere l'ID progetto. Puoi trovare l'ID progetto nella scheda Informazioni sul progetto della console Google Cloud, ed eseguire i comandi specificati di seguito per ciascun valore.
Numero progetto
Per ottenere il numero del progetto utilizzando lo strumento a riga di comando gcloud, esegui questo comando:
gcloud projects describe PROJECT_ID
Il comando restituisce un output simile al seguente:
createTime: '2016-10-13T16:44:28.170Z' lifecycleState: ACTIVE name: project_name parent: id: '433637338589' type: organization projectId: PROJECT_ID projectNumber: 'PROJECT_NUMBER'
ID servizio
Per ottenere l'ID servizio utilizzando lo strumento a riga di comando gcloud, esegui questo comando:
gcloud compute backend-services describe SERVICE_NAME --project=PROJECT_ID --global
Il comando restituisce un output simile al seguente:
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
Recupero dell'identità utente
Se tutte le verifiche precedenti hanno esito positivo, recupera l'identità utente. Il payload del token ID contiene le seguenti informazioni utente:
Identità utente payload token ID | ||
---|---|---|
sub |
Oggetto |
L'identificatore univoco e stabile dell'utente. Utilizza questo valore anziché l'intestazione x-goog-authenticated-user-id .
|
email |
Email dell'utente | Indirizzo email dell'utente.
|
Ecco alcuni codice campione per proteggere un'app con intestazioni IAP firmate:
C#
Go
Java
Node.js
PHP
Python
Ruby
Test del codice di convalida
Se visiti la tua app utilizzando i parametri di query secure_token_test
, IAP includerà un JWT non valido. Utilizzalo per assicurarti che la logica di convalida di JWT gestisca tutti i vari casi di errore e per vedere come si comporta la tua app quando riceve un JWT non valido.
Creazione di un'eccezione del controllo di integrità
Come accennato in precedenza, i controlli di integrità di Compute Engine e GKE non utilizzano intestazioni JWT e IAP non gestisce i controlli di integrità. Per consentire l'accesso al controllo di integrità, devi configurare il controllo di integrità e l'app.
Configurazione del controllo di integrità
Se non hai ancora impostato un percorso per il controllo di integrità, utilizza la console Google Cloud per impostare un percorso non sensibile per il controllo di integrità. Assicurati che questo percorso non sia condiviso da altre risorse.
- Vai alla pagina Controlli di integrità della console Google Cloud.
Vai alla pagina Controlli di integrità - Fai clic sul controllo di integrità che stai utilizzando per la tua app, poi fai clic su Modifica.
- In Percorso richiesta, aggiungi un nome di percorso non sensibile. Questo specifica il percorso dell'URL che Google Cloud utilizza durante l'invio delle richieste di controllo di integrità.
Se omesso, la richiesta di controllo di integrità viene inviata a
/
. - Fai clic su Salva.
Configurazione della convalida JWT
Nel codice che chiama la routine di convalida JWT, aggiungi una condizione per gestire uno stato HTTP 200 per il percorso di richiesta del controllo di integrità. Ad esempio:
if HttpRequest.path_info = '/HEALTH_CHECK_REQUEST_PATH' return HttpResponse(status=200) else VALIDATION_FUNCTION
JWT per identità esterne
Se utilizzi IAP con identità esterne, IAP continuerà a emettere un JWT firmato su ogni richiesta autenticata, proprio come per le identità Google. Tuttavia, ci sono alcune differenze.
Informazioni sul fornitore
Quando si utilizzano identità esterne, il payload JWT conterrà un'attestazione denominata gcip
. Questa rivendicazione contiene informazioni sull'utente, come l'indirizzo email e l'URL della foto, nonché eventuali attributi aggiuntivi specifici del fornitore.
Quello qui sotto è un esempio di JWT per un utente che ha eseguito l'accesso 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"
}',
I campi email
e sub
Se un utente è stato autenticato da Identity Platform, i campi email
e sub
del JWT avranno come prefisso l'emittente del token Identity Platform
e l'ID tenant utilizzato (se presente). Ad esempio:
"email": "securetoken.google.com/PROJECT-ID/TENANT-ID:demo_user@gmail.com", "sub": "securetoken.google.com/PROJECT-ID/TENANT-ID:gZG0yELPypZElTmAT9I55prjHg63"
Controllo dell'accesso con sign_in_attributes
L'utilizzo di IAM non è supportato con identità esterne, ma puoi utilizzare attestazioni incorporate nel campo sign_in_attributes
per controllare l'accesso. Ad esempio, considera un utente che ha eseguito l'accesso utilizzando un provider 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"
}
Potresti aggiungere alla tua applicazione una logica simile al codice riportato di seguito per limitare l'accesso agli utenti con un ruolo valido:
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.
}
È possibile accedere agli attributi utente aggiuntivi dei provider SAML e OIDC di Identity Platform
utilizzando l'attestazione nidificata gcipClaims.gcip.firebase.sign_in_attributes
.
Limitazioni delle dimensioni delle attestazioni dell'IdP
Dopo che un utente accede a Identity Platform, gli attributi utente aggiuntivi vengono propagati al payload del token ID stateless di Identity Platform, che verrà passato in modo sicuro a IAP. IAP emetterà quindi il proprio cookie opaco stateless contenente anch'esso le stesse affermazioni. IAP genererà l'intestazione JWT firmata in base ai contenuti dei cookie.
Di conseguenza, se una sessione viene avviata con un numero elevato di rivendicazioni, potrebbe superare la dimensione massima consentita dei cookie, che in genere è di circa 4 kB nella maggior parte dei browser. Di conseguenza, l'operazione di accesso non andrà a buon fine.
Devi assicurarti che solo le richieste necessarie vengano propagate negli attributi SAML IdP o OIDC. Un'altra opzione è utilizzare le funzioni di blocco per filtrare le rivendicazioni non necessarie per il controllo dell'autorizzazione.
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,
};
}
});