In questa pagina viene descritto come proteggere la tua app con le intestazioni IAP firmate. Quando sono configurati, Identity-Aware Proxy (IAP) utilizza i token web JSON (JWT) per garantire che una richiesta alla tua app sia autorizzata. In questo modo la tua app viene protetta dai seguenti tipi di rischi:
- IAP disabilitato per errore;
- firewall configurati in modo errato.
- Accesso dall'interno del progetto.
Per proteggere correttamente la tua app, devi utilizzare le intestazioni con firma per tutti i tipi di app.
In alternativa, se disponi di un'app dell'ambiente standard di App Engine, puoi 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 ulteriori informazioni, consulta la pagina Creare un'eccezione per il controllo di integrità.
Prima di iniziare
Per proteggere la tua app con le intestazioni firmate devi avere:
- Un'applicazione a cui vuoi che gli utenti si connettano.
- Una libreria JWT di terze parti per la tua lingua che supporta l'algoritmo
ES256
.
Protezione della tua app con le intestazioni IAP
Per proteggere la tua app con JWT in IAP, verifica l'intestazione, il payload e la firma di JWT. Il JWT si trova nell'intestazione della richiesta HTTP
x-goog-iap-jwt-assertion
. Se un utente malintenzionato ignora IAP, può falsificare le intestazioni delle identità non firmate IAP, x-goog-authenticated-user-{email,id}
. IAP JWT fornisce
un'alternativa più sicura.
Le intestazioni con firma offrono sicurezza secondaria nel caso in cui qualcuno ignori 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.
Verificare l'intestazione JWT
Verifica che l'intestazione del JWT sia conforme ai seguenti vincoli:
Rivendicazioni su intestazioni JWT | ||
---|---|---|
alg |
Algoritmo | ES256 |
kid |
ID chiave |
Deve corrispondere a una delle chiavi pubbliche elencate nel file della chiave IAP, disponibile in due formati diversi: 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 alla richiesta kid
del token. Per farlo, devi prima recuperare la chiave pubblica da una delle due seguenti posizioni:
https://www.gstatic.com/iap/verify/public_key
. Questo URL contiene un dizionario JSON che mappa le rivendicazionikid
alle coppie chiave-valore pubbliche.https://www.gstatic.com/iap/verify/public_key-jwk
. Questo URL contiene le chiavi pubbliche IAP in formato JWK.
Una volta che la chiave pubblica è disponibile, utilizza una libreria JWT per verificare la firma.
Verifica del payload JWT
Verifica che il payload JWT sia conforme ai seguenti vincoli:
Richieste di payload JWT | ||
---|---|---|
exp |
Scadenza | Deve essere una data futura. Il tempo viene misurato in secondi dall'epoca di UNIX. Attendi 30 secondi per alterare il disallineamento. La durata massima di un token è 10 minuti + 2 * disallineamenti. |
iat |
Emesso al momento | Deve essere nel passato. Il tempo viene misurato in secondi dall'epoca di UNIX. Attendi 30 secondi per alterare 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, la rivendicazione hd viene fornita per differenziare il dominio a cui è associato l'account.
|
google |
Rivendicazione di Google |
Se uno o più livelli di accesso si applicano alla richiesta, i relativi nomi vengono archiviati all'interno dell'oggetto JSON della rivendicazione google , sotto la chiave access_levels , come un array di stringhe.
Quando specifichi un criterio relativo ai dispositivi e l'organizzazione ha accesso ai dati del dispositivo, |
Puoi ottenere i valori per la stringa aud
sopra menzionata accedendo alla console Google Cloud oppure puoi utilizzare lo strumento a riga di comando gcloud.
Per recuperare i valori della stringa aud
dalla console Google Cloud, vai alle impostazioni di Identity-Aware Proxy per il progetto, fai clic su Altro accanto alla risorsa Bilanciatore del carico, quindi seleziona Segmento di pubblico JWT firmato. Nella finestra di dialogo JWT di intestazione firmata che viene visualizzata viene visualizzata la rivendicazione 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, quindi 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 il comando seguente:
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 il comando seguente:
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à dell'utente. Il payload del token ID contiene le seguenti informazioni utente:
ID utente payload ID token | ||
---|---|---|
sub |
Oggetto |
L'identificatore univoco e stabile dell'utente. Utilizza questo valore invece dell'intestazione x-goog-authenticated-user-id .
|
email |
Email dell'utente | Indirizzo email dell'utente.
|
Ecco alcuni esempi di codice 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 ricerca di secure_token_test
, IAP includerà un JWT non valido. Utilizzalo per assicurarti che la logica di convalida JWT gestisca tutti i vari casi di errore e per vedere il comportamento della tua app quando riceve un JWT non valido.
Creazione di un'eccezione per il controllo di integrità
Come accennato in precedenza, i controlli di integrità di Compute Engine e GKE non utilizzano le intestazioni JWT e IAP non gestisce i controlli di integrità. Dovrai configurare il controllo di integrità e l'app per consentirne l'accesso.
Configurazione del controllo di integrità
Se non hai già 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 utilizzi per la tua app, quindi fai clic su Modifica.
- Nella sezione Percorso richiesta, aggiungi un nome di percorso non sensibile. Specifica il percorso dell'URL utilizzato da Google Cloud durante l'invio di richieste di controllo di integrità.
Se omessa, 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 pubblicare uno stato HTTP 200 per il percorso della richiesta di controllo di integrità. Ad esempio:
if HttpRequest.path_info = '/HEALTH_CHECK_REQUEST_PATH' return HttpResponse(status=200) else VALIDATION_FUNCTION
JWT per le identità esterne
Se utilizzi IAP con identità esterne, IAP emetterà comunque un JWT firmato per ogni richiesta autenticata, proprio come avviene per le identità Google. ma esistono alcune differenze.
Informazioni sul fornitore
Quando utilizzi identità esterne, il payload JWT conterrà una rivendicazione con nome gcip
. Questa rivendicazione contiene informazioni sull'utente, ad esempio l'indirizzo email e l'URL delle foto, nonché eventuali altri attributi specifici del fornitore.
Di seguito è riportato 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 saranno preceduti dal prefisso dell'emittente del token di Identity Platform e dell'eventuale ID tenant utilizzato. 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
in corso...
IAM non è supportato per l'utilizzo con identità esterne, ma puoi utilizzare le rivendicazioni incorporate nel campo sign_in_attributes
per controllare l'accesso. Ad esempio, prendi in considerazione 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"
}
Puoi aggiungere logica all'applicazione in modo simile al codice che segue 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 la rivendicazione nidificata gcipClaims.gcip.firebase.sign_in_attributes
.
IdP - limitazioni di dimensioni delle rivendicazioni
Dopo che un utente esegue l'accesso con Identity Platform, gli attributi utente aggiuntivi verranno propagati al payload del token dell'ID Platform Platform stateless che verrà passato in modo sicuro a IAP. IAP emette quindi un proprio cookie stateless opaco che a sua volta contiene le stesse dichiarazioni. 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 per i cookie, che generalmente è di circa 4 kB nella maggior parte dei browser. In questo modo l'operazione di accesso non andrà a buon fine.
Devi assicurarti che negli attributi IdP SAML o OIDC vengano propagate solo le rivendicazioni necessarie. Un'altra opzione è usare 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,
};
}
});