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. So wird Ihre App vor folgenden Risiken geschützt:
- IAP wurde versehentlich deaktiviert
- Falsch konfigurierte Firewalls
- Unbefugter Zugriff innerhalb des Projekts
Um Ihre App zu schützen, müssen Sie für alle App-Typen signierte Header verwenden.
Wenn Sie eine App in der App Engine-Standardumgebung haben, können Sie alternativ die Users API verwenden.
Compute Engine- und GKE-Systemdiagnosen enthalten keine JWT-Header und IAP verarbeitet keine Systemdiagnosen. Wenn bei der Systemdiagnose Zugriffsfehler zurückgegeben werden, prüfen Sie, ob Sie die Systemdiagnose in der Google Cloud Console richtig konfiguriert haben und ob die JWT-Header-Validierung den Systemdiagnosepfad zulässt. 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-Anfrageheader x-goog-iap-jwt-assertion. Wenn ein Angreifer IAP umgeht, kann er die nicht signierten IAP-Identitätsheader 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, entfernt IAP die vom Client bereitgestellten x-goog-*-Header, wenn die Anfrage über die IAP-Bereitstellungsinfrastruktur erfolgt.
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. |
Achten Sie darauf, dass das JWT mit dem privaten Schlüssel signiert wurde, der der kid-Anforderung des Tokens entspricht. Rufen Sie zuerst den öffentlichen Schlüssel an einem der folgenden Orte 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.
Nachdem Sie den öffentlichen Schlüssel haben, verwenden Sie eine JWT-Bibliothek, um die Signatur zu überprüfen.
IAP rotiert seine öffentlichen Schlüssel regelmäßig. Informationen dazu, wie Sie sicherstellen, dass Sie die JWTs immer überprüfen können, finden Sie unter Caching öffentlicher Schlüssel automatisieren.
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 eine oder mehrere Zugriffsebenen auf die Anfrage zutreffen, werden ihre Namen im JSON-Objekt des google-Claims unter dem Schlüssel access_levels als String-Array gespeichert.
Wenn Sie eine Geräte-Richtlinie angeben und die Organisation Zugriff auf die Gerätedaten hat, wird auch |
Sie können die Werte für den oben genannten aud-String über dieGoogle Cloud -Konsole abrufen oder das gcloud-Befehlszeilentool verwenden.
Wenn Sie aud-Stringwerte aus der Google Cloud -Konsole abrufen möchten, rufen Sie die Identity-Aware Proxy-Einstellungen für Ihr Projekt auf, klicken Sie neben der Load Balancer-Ressource auf das Dreipunkt-Menü und wählen Sie dann JWT-Zielgruppe für signierte Header aus. Im Dialogfeld JWT mit signiertem Header, das angezeigt wird, sehen Sie die aud-Anforderung für die ausgewählte Ressource.
Wenn Sie das gcloud-Befehlszeilentool verwenden möchten, um die aud-Stringwerte abzurufen, benötigen Sie die Projekt-ID. Sie finden die Projekt-ID in der Google Cloud Console auf der Karte Projektinformationen. 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 alle vorherigen Bestätigungen erfolgreich sind, 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.
|
Hier ist ein Beispielcode zum Sichern einer App mit signierten IAP-Headern:
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. So können Sie sicherstellen, dass Ihre JWT-Validierungslogik alle verschiedenen Fehlerfälle abdeckt, und sehen, wie sich Ihre App verhält, wenn sie ein ungültiges JWT empfängt.
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 Ihre Systemdiagnose festgelegt haben, verwenden Sie dieGoogle Cloud Console, um einen nicht vertraulichen Pfad für die Systemdiagnose festzulegen. 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 dieser Parameter nicht angegeben wird, wird die Systemdiagnoseanfrage 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
Caching öffentlicher Schlüssel automatisieren
IAP rotiert seine öffentlichen Schlüssel regelmäßig. Damit Sie das IAP-JWT immer überprüfen können, empfehlen wir, die Schlüssel zu cachen, damit sie nicht für jede Anfrage von der öffentlichen URL abgerufen werden müssen, und den Prozess zum Aktualisieren des gecachten Schlüssels zu automatisieren. Dieser Ansatz ist besonders nützlich für Anwendungen, die in einer Umgebung mit Netzwerkeinschränkungen ausgeführt werden, z. B. in einem VPC Service Controls-Perimeter.
Ein VPC Service Controls-Perimeter kann den direkten Zugriff auf die öffentliche URL für die Schlüssel verhindern. Wenn Sie die Schlüssel in einem Cloud Storage-Bucket zwischenspeichern, können Ihre Anwendungen sie von einem Speicherort innerhalb Ihres VPC SC-Perimeters abrufen.
Mit der folgenden Terraform-Konfiguration wird eine Funktion in Cloud Run bereitgestellt, die die neuesten öffentlichen IAP-Schlüssel von https://www.gstatic.com/iap/verify/public_key-jwk abruft und in einem Cloud Storage-Bucket speichert. Ein Cloud Scheduler-Job löst diese Funktion alle 12 Stunden aus, um die Schlüssel auf dem neuesten Stand zu halten.
Diese Konfiguration umfasst Folgendes:
- Erforderliche Google Cloud APIs aktiviert, um Cloud Run zu verwenden und Schlüssel zu speichern und im Cache zu speichern
- Ein Cloud Storage-Bucket zum Speichern der abgerufenen öffentlichen IAP-Schlüssel
- Ein Cloud Storage-Bucket für das Staging von Cloud Run Functions-Quellcode
- Dienstkonten für Cloud Run Functions und Cloud Scheduler mit den entsprechenden IAM-Berechtigungen
- Python-Funktion zum Abrufen und Speichern von Schlüsseln
- Ein Cloud Scheduler-Job, um die Funktion alle 12 Stunden auszulösen
Verzeichnisstruktur
├── function_source/ │ ├── main.py │ └── requirements.txt ├── main.tf ├── outputs.tf ├── variables.tf └── terraform.tfvars
function_source/main.py
import functions_framework import requests from google.cloud import storage import os # Environment variables to be set in the function configuration BUCKET_NAME = os.environ.get("BUCKET_NAME") OBJECT_NAME = os.environ.get("OBJECT_NAME", "iap_public_keys.jwk") IAP_KEYS_URL = "https://www.gstatic.com/iap/verify/public_key-jwk" @functions_framework.http def update_iap_keys(request): """Fetches IAP public keys from the public URL and stores them in a Cloud Storage bucket.""" if not BUCKET_NAME: print("Error: BUCKET_NAME environment variable not set.") return "BUCKET_NAME environment variable not set.", 500 try: # Fetch the keys response = requests.get(IAP_KEYS_URL) response.raise_for_status() # Raise an exception for bad status codes keys_content = response.text print(f"Successfully fetched keys from {IAP_KEYS_URL}") # Store in Cloud Storage storage_client = storage.Client() bucket = storage_client.bucket(BUCKET_NAME) blob = bucket.blob(OBJECT_NAME) blob.upload_from_string(keys_content, content_type='application/json') print(f"Successfully wrote IAP keys to gs://{BUCKET_NAME}/{OBJECT_NAME}") return f"Successfully updated {OBJECT_NAME} in bucket {BUCKET_NAME}", 200 except requests.exceptions.RequestException as e: print(f"Error fetching keys from {IAP_KEYS_URL}: {e}") return f"Error fetching keys: {e}", 500 except Exception as e: print(f"Error interacting with Cloud Storage: {e}") return f"Error interacting with Cloud Storage: {e}", 500
Ersetzen Sie Folgendes:
-
BUCKET_NAME: der Name Ihres Cloud Storage-Bucket -
OBJECT_NAME: der Name des Objekts, in dem die Schlüssel gespeichert werden sollen
function_source/requirements.txt
functions-framework==3.* requests google-cloud-storage
variables.tf
variable "project_id" { description = "The Google Cloud project ID." type = string default = PROJECT_ID } variable "region" { description = "The Google Cloud region." type = string default = "REGION" } variable "iap_keys_bucket_name" { description = "The name of the Cloud Storage bucket to store IAP keys." type = string default = BUCKET_NAME" } variable "function_source_bucket_name" { description = "The name of the Cloud Storage bucket to store the function source code." type = string default = "BUCKET_NAME_FUNCTION" }
Ersetzen Sie Folgendes:
-
PROJECT_ID: Ihre Google Cloud Projekt-ID -
REGION: Die Region, in der Ressourcen bereitgestellt werden sollen, z. B.us-central1 -
BUCKET_NAME: der Name des Cloud Storage-Bucket, in dem IAP-Schlüssel gespeichert werden -
BUCKET_NAME_FUNCTION: der Name des Cloud Storage-Bucket, in dem der Quellcode der Cloud Run-Funktionen gespeichert ist
main.tf
terraform { required_providers { google = { source = "hashicorp/google" version = ">= 4.50.0" } google-beta = { source = "hashicorp/google-beta" version = ">= 4.50.0" } } } provider "google" { project = var.project_id region = var.region } provider "google-beta" { project = var.project_id region = var.region } # Enable necessary APIs resource "google_project_service" "services" { for_each = toset([ "storage.googleapis.com", "cloudfunctions.googleapis.com", "run.googleapis.com", # Cloud Functions v2 uses Cloud Run "cloudscheduler.googleapis.com", "iamcredentials.googleapis.com", "cloudbuild.googleapis.com" # Needed for Cloud Functions deployment ]) service = each.key disable_on_destroy = false } # Cloud Storage Bucket to store the IAP public keys resource "google_storage_bucket" "iap_keys_bucket" { name = var.iap_keys_bucket_name location = var.region uniform_bucket_level_access = true versioning { enabled = true } lifecycle { prevent_destroy = false # Set to true in production to prevent accidental deletion } } # Cloud Storage Bucket to store the Cloud Function source code resource "google_storage_bucket" "function_source_bucket" { name = var.function_source_bucket_name location = var.region uniform_bucket_level_access = true } # Archive the function source code data "archive_file" "function_source_zip" { type = "zip" source_dir = "${path.module}/function_source" output_path = "${path.module}/function_source.zip" } # Upload the zipped source code to the source bucket resource "google_storage_bucket_object" "function_source_object" { name = "function_source.zip" bucket = google_storage_bucket.function_source_bucket.name source = data.archive_file.function_source_zip.output_path } # Service Account for the Cloud Function resource "google_service_account" "iap_key_updater_sa" { account_id = "iap-key-updater" display_name = "IAP Key Updater Function SA" } # Grant the function's SA permission to write to the IAP keys bucket resource "google_storage_bucket_iam_member" "keys_bucket_writer" { bucket = google_storage_bucket.iap_keys_bucket.name role = "roles/storage.objectAdmin" member = "serviceAccount:${google_service_account.iap_key_updater_sa.email}" } # Cloud Function (v2) resource "google_cloudfunctions2_function" "update_iap_keys_func" { provider = google-beta # CFv2 often has newer features in google-beta name = "update-iap-keys-function" location = var.region build_config { runtime = "python312" entry_point = "update_iap_keys" source { storage_source { bucket = google_storage_bucket.function_source_bucket.name object = google_storage_bucket_object.function_source_object.name } } } service_config { max_instance_count = 1 available_memory = "256M" timeout_seconds = 60 ingress_settings = "ALLOW_ALL" service_account_email = google_service_account.iap_key_updater_sa.email environment_variables = { BUCKET_NAME = google_storage_bucket.iap_keys_bucket.name OBJECT_NAME = "iap_public_keys.jwk" } } depends_on = [ google_project_service.services, google_storage_bucket_iam_member.keys_bucket_writer ] } # Service Account for the Cloud Scheduler job resource "google_service_account" "iap_key_scheduler_sa" { account_id = "iap-key-scheduler" display_name = "IAP Key Update Scheduler SA" } # Grant the Scheduler SA permission to invoke the Cloud Function resource "google_cloudfunctions2_function_iam_member" "invoker" { provider = google-beta project = google_cloudfunctions2_function.update_iap_keys_func.project location = google_cloudfunctions2_function.update_iap_keys_func.location cloud_function = google_cloudfunctions2_function.update_iap_keys_func.name role = "roles/cloudfunctions.invoker" member = "serviceAccount:${google_service_account.iap_key_scheduler_sa.email}" } # Cloud Scheduler Job resource "google_cloud_scheduler_job" "iap_key_update_schedule" { name = "iap-key-update-schedule" description = "Fetches IAP public keys and stores them in Cloud Storage every 12 hours" schedule = "0 */12 * * *" # Every 12 hours time_zone = "Etc/UTC" region = var.region http_target { uri = google_cloudfunctions2_function.update_iap_keys_func.service_config[0].uri http_method = "POST" oidc_token { service_account_email = google_service_account.iap_key_scheduler_sa.email } } depends_on = [ google_cloudfunctions2_function_iam_member.invoker, google_project_service.services ] }
outputs.tf
output "iap_keys_bucket_url" { description = "The Cloud Storage bucket URL where IAP public keys are stored." value = "gs://${google_storage_bucket.iap_keys_bucket.name}" } output "cloud_function_url" { description = "The URL of the Cloud Function endpoint that triggers key updates." value = google_cloudfunctions2_function.update_iap_keys_func.service_config[0].uri }
terraform.tfvars
Erstellen Sie eine terraform.tfvars-Datei, um Ihre Projekt-ID anzugeben und bei Bedarf Bucket-Namen anzupassen:
project_id = "your-gcp-project-id" # Optional: Customize bucket names # iap_keys_bucket_name = "custom-iap-keys-bucket" # function_source_bucket_name = "custom-func-src-bucket"
Mit Terraform bereitstellen
- Speichern Sie die Dateien in der zuvor beschriebenen Verzeichnisstruktur.
- Wechseln Sie in Ihrem Terminal zum Verzeichnis und initialisieren Sie Terraform:
terraform init - Änderungen planen:
terraform plan - Übernehmen Sie die Änderung:
terraform apply
Dadurch wird die Infrastruktur bereitgestellt. Der Cloud Scheduler-Job löst die Funktion alle 12 Stunden aus, ruft die IAP-Schlüssel ab und speichert sie standardmäßig in gs://BUCKET_NAME/iap_public_keys.jwk. Ihre Anwendungen können die Schlüssel jetzt aus diesem Bucket abrufen.
Ressourcen bereinigen
Führen Sie die folgenden Befehle aus, um die von Terraform erstellten Ressourcen zu entfernen:
gsutil rm -a gs://BUCKET_NAME/** terraform destroy -auto-approve
Ersetzen Sie BUCKET_NAME durch den Cloud Storage-Bucket für Ihre Schlüssel.
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. Dieser Anspruch enthält Nutzerinformationen wie die E‑Mail-Adresse, die Foto-URL und alle zusätzlichen anbieterspezifischen 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 unterstützt keine externen Identitäten, aber Sie können den Zugriff mithilfe von Ansprüchen steuern, die im Feld sign_in_attributes eingebettet sind. Beispiel: Ein Nutzer ist über einen SAML-Anbieter angemeldet:
{
"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.
}
Über den verschachtelten Anspruch gcipClaims.gcip.firebase.sign_in_attributes können Sie auf zusätzliche Nutzerattribute von Identity Platform-SAML- und OIDC-Anbietern zugreifen.
Größenbeschränkungen für IdP-Claims
Nachdem sich ein Nutzer mit Identity Platform angemeldet hat, werden die zusätzlichen Nutzerattribute in die Nutzlast des zustandslosen Identity Platform-ID-Tokens übertragen, die sicher an IAP übergeben wird. IAP stellt dann ein eigenes zustandsloses, intransparentes Cookie aus, das dieselben Behauptungen enthält. IAP generiert den signierten JWT-Header basierend auf dem Cookie-Inhalt.
Wenn eine Sitzung mit vielen Ansprüchen initiiert wird, kann die maximal zulässige Cookie-Größe überschritten werden. Diese beträgt in den meisten Browsern in der Regel etwa 4 KB. Dadurch schlägt die Anmeldung fehl.
Achten Sie darauf, dass nur die erforderlichen Ansprüche in den SAML- oder OIDC-Attributen des IdP weitergegeben werden. Eine weitere Möglichkeit besteht darin, Blockierfunktionen zu verwenden, um die Anforderungen herauszufiltern, die für die Autorisierungsprü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,
};
}
});