Questa pagina descrive come proteggere la tua app con intestazioni IAP firmate. Se configurato, Identity-Aware Proxy (IAP) utilizza i token web JSON (JWT) per assicurarsi che una richiesta alla tua app sia autorizzata. In questo modo, la tua app è protetta dai seguenti rischi:
- L'IAP è disattivato per errore.
- Firewall configurati in modo errato.
- Accedi 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 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 le intestazioni JWT e che IAP non gestisce i controlli di integrità. Se 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à dell'integrità. Per ulteriori informazioni, consulta Creare un'eccezione per i controllo di integrità integrità.
Prima di iniziare
Per proteggere la tua app con intestazioni firmate, devi disporre di 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 intestazioni IAP
Per proteggere la tua 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 malintenzionato aggira IAP, può falsificare le intestazioni di identità non firmate di IAP,x-goog-authenticated-user-{email,id}
. Il JWT IAP offre un'alternativa più sicura.
Le intestazioni firmate forniscono una sicurezza secondaria nel caso in cui qualcuno aggiri
la piattaforma IAP. Tieni presente che, quando l'IAP è attivato, vengono rimossi gli intestazioni x-goog-*
forniti dal client quando la richiesta viene inoltrata all'infrastruttura di pubblicazione IAP.
Verifica dell'intestazione JWT
Verifica che l'intestazione JWT sia conforme ai seguenti vincoli:
Claim dell'intestazione JWT | ||
---|---|---|
alg |
Algoritmo | ES256 |
kid |
ID chiave |
Deve corrispondere a una delle chiavi pubbliche elencate nel
file della chiave 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 con la chiave privata corrispondente alla rivendicazione kid
del token. Per farlo, devi prima recuperare la chiave pubblica da una delle due posizioni seguenti:
https://www.gstatic.com/iap/verify/public_key
. Questo URL contiene un dizionario JSON che mappa i claimkid
ai valori della 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:
Dichiarazioni del payload JWT | ||
---|---|---|
exp |
Scadenza | Deve essere una data futura. Il tempo viene misurato in secondi dall'epoca UNIX. Attendi 30 secondi per lo squilibrio. La durata massima di un token è 10 minuti + 2 * skew. |
iat |
Data/ora di emissione | Deve essere nel passato. Il tempo viene misurato in secondi dall'epoca UNIX. Attendi 30 secondi per lo squilibrio. |
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 fornito il reclamo hd per distinguere il dominio a cui è associato l'account.
|
google |
Richiesta di Google |
Se alla richiesta si applicano uno o più livelli di accesso, i relativi nomi vengono memorizzati nell'oggetto JSON della rivendicazione google , sotto la chiave access_levels , come array di stringhe.
Quando specifichi un criterio del dispositivo e l'organizzazione ha accesso ai dati del dispositivo, |
Puoi ottenere i valori per la stringa aud
menzionata sopra accedendo alla console Google Cloud o utilizzando lo strumento a riga di comando gcloud.
Per ottenere i valori di stringa aud
dalla console Google Cloud, vai alle impostazioni di Proxy aware delle identità per il tuo progetto, fai clic su Altro accanto alla risorsa Load Balancer e poi seleziona Pubblico JWT con intestazione firmata. Nella finestra di dialogo JWT con intestazione firmata visualizzata viene mostrato il claim aud
per la risorsa selezionata.
Se vuoi utilizzare lo strumento a riga di comando gcloud gcloud CLI per recuperare i valori delle stringhe 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 ogni valore.
Numero progetto
Per ottenere il numero di progetto utilizzando lo strumento a riga di comando gcloud, esegui il seguente 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 recuperare l'ID servizio utilizzando lo strumento a riga di comando gcloud, esegui il seguente 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 sono andate a buon fine, recupera l'identità utente. Il payload del token ID contiene le seguenti informazioni sull'utente:
Id utente del payload dell'ID token | ||
---|---|---|
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.
|
Di seguito è riportato un codice campione per proteggere un'app con intestazioni IAP firmate:
C#
Go
Java
Node.js
PHP
Python
Ruby
Testare il 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 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 per il controllo di integrità
Come accennato in precedenza, i controlli di salute di Compute Engine e GKE non utilizzano le intestazioni JWT e IAP non gestisce i controlli di salute. Dovrai configurare il controllo di integrità e l'app per consentire l'accesso al controllo di integrità.
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 utilizzi per la tua app e poi su Modifica.
- In Percorso richiesta, aggiungi un nome di percorso non sensibile. Questo specifica il percorso dell'URL utilizzato da Google Cloud per inviare 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 restituire un stato HTTP 200 per il percorso della richiesta di controllo di integrità'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, come avviene per le identità Google. Esistono, tuttavia, alcune differenze.
Informazioni sul fornitore
Quando utilizzi identità esterne, il payload JWT conterrà un'affermazione
chiamata gcip
. Questa rivendicazione contiene informazioni sull'utente, ad esempio l'email e l'URL della foto, nonché eventuali attributi aggiuntivi 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, ai campi email
e sub
del JWT verrà anteposto l'emittente del token di 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
IAM non è supportato per l'utilizzo con le identità esterne, ma puoi utilizzare i claim incorporati 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 ad altri attributi utente dei provider SAML e OIDC di Identity Platform utilizzando il claim gcipClaims.gcip.firebase.sign_in_attributes
nidificato.
Limiti di dimensione delle rivendicazioni dell'identità provider
Dopo che un utente ha eseguito l'accesso con Identity Platform, gli attributi utente aggiuntivi vengono propagati al payload del token ID di Identity Platform senza stato, che viene trasmesso in modo sicuro a IAP. L'IAP emetterà quindi il proprio cookie opaco stateless contenente anche gli stessi claim. IAP genererà l'intestazione JWT firmata in base al contenuto del cookie.
Di conseguenza, se una sessione viene avviata con un numero elevato di rivendicazioni, potrebbe superare le dimensioni massime consentite per i cookie, che in genere sono circa 4 KB nella maggior parte dei browser. L'operazione di accesso non andrà a buon fine.
Devi assicurarti che solo i claim necessari vengano propagati negli attributi SAML o OIDC dell'IdP. Un'altra opzione è utilizzare 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,
};
}
});