Auf dieser Seite wird gezeigt, wie Sie Ihre Anwendung mit signierten IAP-Headern schützen können. Bei entsprechender Konfiguration sorgt Identity-Aware Proxy (IAP) mit JSON-Web-Tokens (JWTs) dafür, dass eine Anfrage an Ihre Anwendung autorisiert ist. Dies schützt Ihre Anwendung vor folgenden Risiken:
- IAP wurde versehentlich deaktiviert;
- falsch konfigurierte Firewalls;
- Zugriffe aus dem Projekt
Für eine ordnungsgemäße Sicherung der Anwendung müssen Sie für alle Anwendungstypen signierte Header verwenden.
Wenn Sie mit einer App Engine-Standardumgebung arbeiten, können Sie auch die User API verwenden.
Beachten Sie, dass die Compute Engine- und GKE-Systemdiagnosen keine JWT-Header verwenden und IAP keine Systemdiagnosen verarbeitet. Wenn bei der Systemdiagnose Zugriffsfehler zurückgegeben werden, müssen Sie prüfen, ob sie in der Google Cloud Console korrekt konfiguriert wurde und ob der Pfad der Systemdiagnose für die Validierung der JWT-Header zugelassen ist. Weitere Informationen finden Sie unter Ausnahme für Systemdiagnose erstellen.
Hinweis
Um Ihre Anwendung mit signierten Headern zu schützen, muss Folgendes vorhanden sein:
- Eine Anwendung, mit der Nutzer eine Verbindung herstellen sollen
- Eine JWT-Bibliothek eines Drittanbieters für Ihre Sprache, die den
ES256
-Algorithmus unterstützt
Anwendung mit IAP-Headern schützen
Für den Schutz Ihrer Anwendung mit dem IAP-JWT müssen Sie den Header, die Nutzlast und die Signatur des JWT prüfen. Das JWT befindet sich im HTTP-Anfrage-Header x-goog-iap-jwt-assertion
. Wenn ein Angreifer IAP umgeht, kann er die nicht signierten IAP-Identitäts-Header x-goog-authenticated-user-{email,id}
fälschen. Das IAP-JWT stellt dazu eine sicherere Alternative dar.
Signierte Header bieten eine sekundäre Sicherheit, wenn jemand IAP umgeht. Wenn IAP aktiviert ist, werden die vom Client bereitgestellten x-goog-*
-Header entfernt, wenn die Anfrage über die IAP-Bereitstellungsinfrastruktur ausgeführt wird.
JWT-Header prüfen
Prüfen Sie, ob der Header des JWT den folgenden Anforderungen genügt:
Anforderungen an den JWT-Header | ||
---|---|---|
alg |
Algorithmus | ES256 |
kid |
Schlüssel-ID | Muss einem der öffentlichen Schlüssel entsprechen, die in der IAP-Schlüsseldatei aufgeführt und in zwei verschiedenen Formaten verfügbar sind: https://www.gstatic.com/iap/verify/public_key und https://www.gstatic.com/iap/verify/public_key-jwk . |
Prüfen Sie, ob das JWT mit dem privaten Schlüssel signiert wurde, der der Anforderung kid
des Tokens entspricht. Rufen Sie dazu zuerst den öffentlichen Schlüssel von einem der beiden folgenden URLs ab:
https://www.gstatic.com/iap/verify/public_key
. Diese URL enthält ein JSON-Wörterbuch, das diekid
-Anforderungen den öffentlichen Schlüsselwerten zuordnet.https://www.gstatic.com/iap/verify/public_key-jwk
. Diese URL enthält die öffentlichen IAP-Schlüssel im Format JWK.
Wenn der öffentliche Schlüssel verfügbar ist, prüfen Sie die Signatur mithilfe einer JWT-Bibliothek.
JWT-Nutzlast prüfen
Prüfen Sie, ob die Nutzlast des JWT den folgenden Anforderungen genügt:
Anforderungen an die JWT-Nutzlast | ||
---|---|---|
exp |
Ablaufzeit | Muss in der Zukunft liegen. Die Zeit wird in Sekunden seit der UNIX-Epoche gemessen. Rechnen Sie rund 30 Sekunden Verzögerung ein. Die maximale Lebensdauer eines Tokens beträgt 10 Minuten + 2 * Verzögerung. |
iat |
Ausstellungszeit | Muss in der Vergangenheit liegen.j Die Zeit wird in Sekunden seit der UNIX-Epoche gemessen. Rechnen Sie rund 30 Sekunden Verzögerung ein. |
aud |
Zielgruppe | Muss ein String mit folgenden Werten sein:
|
iss |
Aussteller | Muss https://cloud.google.com/iap lauten. |
hd |
Kontodomain | Wenn ein Konto zu einer gehosteten Domain gehört, wird die Anforderung hd bereitgestellt, um die Domain, der das Konto zugeordnet ist, identifizieren zu können. |
google |
Google-Anforderung |
Wenn für die Anfrage eine oder mehrere Zugriffsebenen gelten, werden ihre Namen im JSON-Objekt der google -Anforderung unter dem Schlüssel access_levels als String-Array gespeichert.
Wenn Sie eine Geräterichtlinie angeben und die Organisation Zugriff auf die Gerätedaten hat, wird |
Sie können die oben genannten Werte für den String aud
mithilfe der Google Cloud Console oder des gcloud-Befehlszeilentools abrufen.
Zum Abrufen der aud
-Stringwerte in der Google Cloud Console öffnen Sie die Identity-Aware Proxy-Einstellungen für Ihr Projekt und klicken neben der Load Balancer-Ressource auf das Dreipunkt-Menü. Wählen Sie dann Signed Header JWT Audience (Zielgruppe für JWT mit signiertem Header) aus. Im anschließend eingeblendeten Dialogfeld JWT mit signiertem Header wird die aud
-Anforderung für die ausgewählte Ressource angezeigt.
Wenn Sie die aud
Stringwerte mit dem gcloud-Befehlszeilentool der gcloud CLI abrufen möchten, müssen Sie die Projekt-ID kennen. Sie finden die Projekt-ID auf der Karte Projektinformationen der Google Cloud Console. Führen Sie dann die angegebenen Befehle für jeden Wert aus.
Projektnummer
Um mit dem gcloud-Befehlszeilentool die Projekt-ID abzurufen, führen Sie den folgenden Befehl aus:
gcloud projects describe PROJECT_ID
Der Befehl gibt in etwa Folgendes zurück:
createTime: '2016-10-13T16:44:28.170Z' lifecycleState: ACTIVE name: project_name parent: id: '433637338589' type: organization projectId: PROJECT_ID projectNumber: 'PROJECT_NUMBER'
Dienst-ID
Um mit dem gcloud-Befehlszeilentool die Dienst-ID abzurufen, führen Sie den folgenden Befehl aus:
gcloud compute backend-services describe SERVICE_NAME --project=PROJECT_ID --global
Der Befehl gibt in etwa Folgendes zurück:
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
Nutzeridentität abrufen
Wenn die oben genannten Prüfungen erfolgreich abgeschlossen wurden, rufen Sie die Nutzeridentität ab. Die Nutzlast des ID-Tokens enthält folgende Nutzerinformationen:
Nutzeridentität in der Nutzlast des ID-Tokens | ||
---|---|---|
sub |
Betreff |
Die eindeutige, stabile Kennung für den Nutzer. Verwenden Sie diesen Wert anstelle des Headers x-goog-authenticated-user-id .
|
email |
E-Mail-Adresse des Nutzers | Die E-Mail-Adresse des Nutzers.
|
Mit dem folgenden Beispielcode wird eine Anwendung mit signierten IAP-Headern geschützt:
C#
Go
Java
Node.js
PHP
Python
Ruby
Validierungscode testen
Wenn Sie Ihre Anwendung mit den Abfrageparametern secure_token_test
aufrufen, enthält IAP ein ungültiges JWT. Damit können Sie sicherstellen, dass Ihre JWT-Validierungslogik alle denkbaren Fehlerszenarien abdeckt, und prüfen, wie sich Ihre Anwendung bei einem ungültigen JWT verhält.
Ausnahme für Systemdiagnose erstellen
Wie bereits erwähnt, verwenden die Compute Engine- und GKE-Systemdiagnosen keine JWT-Header und IAP verarbeitet keine Systemdiagnosen. Sie müssen also die Systemdiagnose und die Anwendung so konfigurieren, dass der Zugriff auf die Systemdiagnose zulässig ist.
Systemdiagnose konfigurieren
Wenn Sie noch keinen Pfad für die Systemdiagnose festgelegt haben, geben Sie in der Google Cloud Console einen nicht vertraulichen Pfad dafür an. Achten Sie darauf, dass dieser Pfad von keiner anderen Ressource verwendet wird.
- Rufen Sie in der Google Cloud Console die Seite Systemdiagnosen auf.
Zur Seite "Systemdiagnosen" - Klicken Sie auf die Systemdiagnose, die Sie für Ihre Anwendung verwenden, und anschließend auf Bearbeiten.
- Fügen Sie unter Anfragepfad einen nicht vertraulichen Pfadnamen hinzu. Gibt den URL-Pfad an, den Google Cloud beim Senden von Systemdiagnoseanfragen verwendet.
Wenn nichts angegeben ist, werden Systemdiagnoseanfragen an
/
gesendet. - Klicken Sie auf Speichern.
JWT-Validierung konfigurieren
Fügen Sie dem Code, der die JWT-Validierungsroutine aufruft, eine Bedingung hinzu, die den HTTP-Status 200 für den Systemdiagnoseanfragepfad ausgibt. Beispiel:
if HttpRequest.path_info = '/HEALTH_CHECK_REQUEST_PATH' return HttpResponse(status=200) else VALIDATION_FUNCTION
JWTs für externe Identitäten
Wenn Sie IAP mit externen Identitäten verwenden, gibt IAP wie bei Google-Identitäten weiterhin ein signiertes JWT bei jeder authentifizierten Anfrage aus. Es gibt jedoch einige Unterschiede.
Anbieterinformationen
Bei Verwendung externer Identitäten enthält die JWT-Nutzlast eine Anforderung namens gcip
. Diese Anforderung beinhaltet Informationen über den Nutzer, z. B. seine E-Mail-Adresse und seine Foto-URL, sowie zusätzliche anbieterspezifische Attribute.
Im Folgenden finden Sie ein Beispiel für das JWT eines Nutzers, der sich mit Facebook angemeldet hat:
"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"
}',
Die Felder email
und sub
Wenn ein Nutzer von Identity Platform authentifiziert wurde, werden den Feldern email
und sub
des JWT der Tokenaussteller von Identity Platform und die verwendete Mandanten-ID (wenn vorhanden) vorangestellt. Beispiel:
"email": "securetoken.google.com/PROJECT-ID/TENANT-ID:demo_user@gmail.com", "sub": "securetoken.google.com/PROJECT-ID/TENANT-ID:gZG0yELPypZElTmAT9I55prjHg63"
Zugriff mit sign_in_attributes
steuern
IAM wird nicht für die Verwendung externer Identitäten unterstützt. Sie können stattdessen aber den Zugriff mit Anforderungen steuern, die im Feld sign_in_attributes
eingebettet sind. Angenommen, ein Nutzer meldet sich mit einem SAML-Anbieter an:
{
"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"
}
Sie können der Anwendung dann eine Logik wie mit dem folgenden Code hinzufügen und so den Zugriff auf Nutzer mit einer gültigen Rolle einschränken:
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.
}
Zusätzliche Nutzerattribute von Identity Platform-SAML- und -OIDC-Anbietern können über die verschachtelte Anforderung gcipClaims.gcip.firebase.sign_in_attributes
aufgerufen werden.
Größenbeschränkungen für IdP-Anspruch
Nachdem sich ein Nutzer über die Identity Platform angemeldet hat, werden die zusätzlichen Nutzerattribute an die zustandslose Identity Platform-ID-Token-Nutzlast übertragen, die dann sicher an IAP übergeben wird. IAP stellt dann ein eigenes zustandsloses, undurchsichtiges Cookie aus, das ebenfalls dieselben Ansprüche enthält. IAP generiert den signierten JWT-Header basierend auf dem Cookie-Inhalt.
Wenn also eine Sitzung mit einer großen Anzahl von Ansprüchen gestartet wird, wird möglicherweise die maximal zulässige Cookie-Größe überschritten, die in den meisten Browsern in der Regel etwa 4 KB beträgt. Dies führt dazu, dass die Anmeldung fehlschlägt.
Achten Sie darauf, dass nur die erforderlichen Berechtigungen in den SAML- oder OIDC-Attributen des IdP weitergegeben werden. Eine weitere Möglichkeit besteht darin, mithilfe von Blockierfunktionen Ansprüche herauszufiltern, die für die Autorisierungsüberprüfung nicht erforderlich sind.
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,
};
}
});