In questa pagina viene descritto come proteggere l'app con intestazioni IAP firmate. Se configurato, Identity-Aware Proxy (IAP) utilizza i token Web JSON (JWT) per garantire che una richiesta alla tua app venga autorizzata. In questo modo la tua app viene protetta dai seguenti tipi di rischio:
- IAP disattivato accidentalmente;
- Firewall configurati in modo errato.
- Accesso dall'interno del progetto.
Per proteggere correttamente l'app, devi utilizzare le intestazioni firmate per tutti i tipi di app.
In alternativa, se hai un'app per l'ambiente standard di App Engine, puoi utilizzare l'API Users.
Tieni presente che i controlli di integrità di Compute Engine e GKE non includono intestazioni JWT e IAP non gestisce i controlli di integrità. Se il controllo di integrità restituisce errori di accesso, assicurati che sia configurato correttamente in Google Cloud Console e che la convalida dell'intestazione JWT consenta il percorso del controllo di integrità. Per ulteriori informazioni, consulta Creare un'eccezione per il controllo di integrità.
Prima di iniziare
Per proteggere la tua app con intestazioni firmate, devi disporre di:
- Un'applicazione a cui vuoi che gli utenti si connettano.
- Una libreria di JWT di terze parti per la tua lingua che supporta
l'algoritmo
ES256
.
Protezione dell'app con intestazioni IAP
Per proteggere la tua app con IAP JWT, verifica l'intestazione,
il payload e la firma di JWT. JWT è nell'intestazione della richiesta HTTP x-goog-iap-jwt-assertion
. Se un utente malintenzionato ignora IAP, può falsificare le intestazioni dell'identità non firmate IAP, x-goog-authenticated-user-{email,id}
. Lo IAP JWT offre un'alternativa più sicura.
Le intestazioni con firma offrono sicurezza secondaria in caso di bypass di un IAP. Tieni presente che, quando è attivato, IAP 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 di JWT' sia conforme ai seguenti vincoli:
Dichiarazioni intestazione JWT | ||
---|---|---|
alg |
Algoritmo | ES256 |
kid |
ID chiave |
Deve corrispondere a una delle chiavi pubbliche elencate nel file delle chiavi 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 rivendicazione kid
del token. Per farlo, devi prima recuperare la chiave pubblica in uno dei due seguenti posti:
https://www.gstatic.com/iap/verify/public_key
. Questo URL contiene un dizionario JSON che mappa le rivendicazioni dikid
ai valori delle chiavi pubbliche.https://www.gstatic.com/iap/verify/public_key-jwk
. Questo URL contiene le chiavi pubbliche IAP in formato JWK.
Una volta creata la chiave pubblica, utilizza una libreria JWT per verificare la firma.
Verifica del payload JWT
Verifica che il payload di JWT sia conforme ai seguenti vincoli:
Richieste di payload JWT | ||
---|---|---|
exp |
Scadenza | Deve essere nel futuro. Il tempo viene misurato in secondi dal periodo UNIX. Attendi 30 secondi per alterare. La durata massima di un token è di 10 minuti + 2 * disallineamento. |
iat |
Emesso al momento | Deve essere nel passato. Il tempo viene misurato in secondi dal periodo UNIX. Attendi 30 secondi per alterare. |
aud |
Pubblico |
Deve essere una stringa con i seguenti valori:
|
iss |
Emittente |
Deve essere https://cloud.google.com/iap .
|
hd |
Dominio account |
Se un account appartiene a un dominio ospitato, la rivendicazione hd viene fornita per distinguere il dominio a cui è associato.
|
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 di 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 della stringa aud
menzionata sopra accedendo a Google Cloud Console o puoi utilizzare lo strumento a riga di comando gcloud.
Per ottenere i valori della stringa aud
da Google Cloud Console, 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 dell'intestazione firmata. Nella finestra di dialogo Intestazione firmata viene visualizzata la richiesta 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 di Google Cloud Console, quindi esegui i comandi specificati di seguito per ciascun valore.
Numero progetto
Per ottenere il numero del tuo 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:
ID utente payload payload ID | ||
---|---|---|
sub |
Oggetto |
L'identificatore univoco e stabile dell'utente. Utilizza questo valore anziché l'intestazione x-goog-authenticated-user-id .
|
email |
Indirizzo email dell'utente | Indirizzo email dell'utente.
|
Ecco un codice di esempio per proteggere un'app con intestazioni IAP firmate:
C#
Go
Java
Node.js
PHP
Python
Ruby
Test del codice di convalida in corso...
Se visiti la tua app utilizzando i
parametri di query di secure_token_test
,
IAP includerà un JWT non valido. Utilizza questa opzione per assicurarti che la logica di convalida JWT gestisca tutti i vari casi di errore e per vedere il comportamento dell'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 intestazioni JWT, mentre IAP non gestisce i controlli di integrità. Dovrai configurare il tuo controllo di integrità e l'app per consentirne l'accesso.
Configurazione del controllo di integrità in corso...
Se non hai già impostato un percorso per il controllo di integrità, utilizza Google Cloud Console per impostare un percorso non sensibile per il controllo di integrità. Assicurati che questo percorso non sia condiviso da nessun'altra risorsa.
- Vai alla pagina Controlli di integrità di Google Cloud Console.
Vai alla pagina Controlli di integrità - Fai clic sul controllo di integrità che stai utilizzando per l'app, quindi fai clic su Modifica.
- In Percorso richiesta, aggiungi un nome di percorso non sensibile. Specifica il percorso dell'URL che Google Cloud utilizza quando invia 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 lo stato HTTP 200 per il tuo percorso di richiesta di 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 emetterà comunque un JWT firmato su ogni richiesta autenticata, proprio come avviene con le identità Google. Tuttavia, esistono alcune differenze.
Informazioni sul fornitore
Quando utilizzi identità esterne, il payload di JWT conterrà una dichiarazione denominata gcip
. Questa rivendicazione contiene informazioni sull'utente, ad esempio l'email e l'URL delle foto, nonché 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
di JWT avranno come prefisso l'emittente del token di Identity Platform e l'ID tenant eventualmente 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
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, supponiamo che un utente abbia 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 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 dai provider SAML e OIDC di Identity Platform
utilizzando la dichiarazione nidificata gcipClaims.gcip.firebase.sign_in_attributes
.
Limitazioni delle dimensioni delle rivendicazioni dell'IdP
Dopo che un utente esegue l'accesso con Identity Platform, gli attributi utente aggiuntivi vengono propagati al payload del token ID Identity Platform stateless, che viene passato in modo sicuro a IAP. IAP quindi emetterà il proprio cookie stateless opaco che contiene le stesse affermazioni. IAP genererà l'intestazione JWT firmata in base ai contenuti del cookie.
Di conseguenza, se una sessione viene avviata con un numero elevato di rivendicazioni, potrebbe superare la dimensione massima consentita per i cookie, che in genere è di circa 4 kB nella maggior parte dei browser. Questa operazione non riuscirà.
Devi assicurarti che negli attributi SAML IdP o OIDC vengano propagate solo le rivendicazioni necessarie. Un'altra opzione è quella di utilizzare le funzioni di blocco per filtrare le rivendicazioni non necessarie per il controllo delle autorizzazioni.
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,
};
}
});