בדף הזה מוסבר איך לאבטח את האפליקציה באמצעות כותרות חתומות של IAP. אחרי שמגדירים את שרת ה-Proxy לאימות זהויות (IAP), הוא משתמש באסימוני אינטרנט מסוג JSON (JWT) כדי לוודא שהבקשה לאפליקציה מאושרת. כך האפליקציה מוגנת מפני הסיכונים הבאים:
- IAP מושבת בטעות
- חומות אש שהוגדרו באופן שגוי
- גישה לא מורשית מתוך הפרויקט
כדי לאבטח את האפליקציה, צריך להשתמש בכותרות חתומות בכל סוגי האפליקציות.
לחלופין, אם יש לכם אפליקציה בסביבת ברירת המחדל ב-App Engine, אתם יכולים להשתמש ב-Users API.בדיקות תקינות של Compute Engine ו-GKE לא כוללות כותרות JWT, ו-IAP לא מעבד בדיקות תקינות. אם בדיקת התקינות מחזירה שגיאות גישה, ודאו שהגדרתם נכון את בדיקת התקינות במסוף Google Cloud , ושהאימות של כותרת ה-JWT מאפשר את הנתיב של בדיקת התקינות. מידע נוסף מופיע במאמר יצירת חריגה לבדיקת תקינות.
לפני שמתחילים
כדי לאבטח את האפליקציה באמצעות כותרות חתומות, צריך:
- אפליקציה שאתם רוצים שהמשתמשים יתחברו אליה.
- ספריית JWT של צד שלישי לשפה שלכם שתומכת באלגוריתם
ES256.
אבטחת האפליקציה באמצעות כותרות IAP
כדי לאבטח את האפליקציה באמצעות ה-JWT של IAP, צריך לאמת את הכותרת, המטען הייעודי והחתימה של ה-JWT. ה-JWT נמצא בכותרת בקשת ה-HTTP x-goog-iap-jwt-assertion. אם תוקף עוקף את IAP, הוא יכול לזייף את כותרות הזהות הלא חתומות של IAP, x-goog-authenticated-user-{email,id}. IAP JWT מספק חלופה מאובטחת יותר.
כותרות חתומות מספקות אבטחה משנית למקרה שמישהו עוקף את IAP. כשה-IAP מופעל, הוא מסיר את הכותרות של x-goog-* שסופקו על ידי הלקוח כשהבקשה עוברת דרך תשתית השירות של ה-IAP.
אימות הכותרת של ה-JWT
מוודאים שהכותרת של ה-JWT עומדת בדרישות הבאות:
| הצהרות בכותרת JWT | ||
|---|---|---|
alg |
אלגוריתם | ES256 |
kid |
מזהה המפתח |
הוא חייב להתאים לאחד מהמפתחות הציבוריים שרשומים בקובץ המפתחות של IAP, שזמין בשני פורמטים שונים:
https://www.gstatic.com/iap/verify/public_key
וגם
https://www.gstatic.com/iap/verify/public_key-jwk
|
מוודאים שה-JWT נחתם על ידי המפתח הפרטי שתואם לטענת kid של האסימון. קודם כל, מאחזרים את המפתח הציבורי מאחד משני מקומות:
-
https://www.gstatic.com/iap/verify/public_key. כתובת ה-URL הזו מכילה מילון JSON שממפה את ההצהרות שלkidלערכים של המפתח הציבורי. -
https://www.gstatic.com/iap/verify/public_key-jwk. כתובת ה-URL הזו מכילה את המפתחות הציבוריים של IAP בפורמט JWK.
אחרי שמקבלים את המפתח הציבורי, משתמשים בספריית JWT כדי לאמת את החתימה.
המערכת של IAP מבצעת רוטציה של המפתחות הציבוריים שלה מדי פעם. כדי לוודא שתמיד תוכלו לאמת את אסימוני ה-JWT, עיינו בקטע אוטומציה של שמירת מפתחות ציבוריים במטמון.
אימות המטען הייעודי (payload) של ה-JWT
מוודאים שה-payload של ה-JWT עומד במגבלות הבאות:
| הצהרות על המטען הייעודי (payload) של JWT | ||
|---|---|---|
exp |
מועד התפוגה | התאריך חייב להיות בעתיד. הזמן נמדד בשניות מאז ראשית זמן יוניקס (Unix epoch). צריך להמתין 30 שניות עד שההטיה תתבצע. משך החיים המקסימלי של אסימון הוא 10 דקות + 2 * סטייה. |
iat |
שעת ההנפקה | התאריך חייב להיות בעבר. הזמן נמדד בשניות מאז ראשית זמן יוניקס (Unix epoch). צריך להמתין 30 שניות עד שההטיה תתבצע. |
aud |
קהל |
צריך להיות מחרוזת עם הערכים הבאים:
|
iss |
מנפיק |
חייב להיות https://cloud.google.com/iap.
|
hd |
הדומיין של החשבון |
אם החשבון שייך לדומיין מתארח, הטענה hd מסופקת כדי להבדיל בין הדומיין שהחשבון משויך אליו.
|
google |
הטענה של Google |
אם רמת גישה אחת או יותר חלה על הבקשה, השמות שלהן מאוחסנים באובייקט ה-JSON של ההצהרה google, מתחת למפתח access_levels, כמערך של מחרוזות.
כשמציינים מדיניות מכשיר ולארגון יש גישה לנתוני המכשיר, גם ה- |
aud שצוינה למעלה, אפשר להיכנס למסוףGoogle Cloud או להשתמש ב-Google Cloud CLI.
כדי לקבל את ערכי המחרוזת של aud ממסוף Google Cloud , נכנסים להגדרות שרת ה-proxy לאימות זהויות (IAP) בפרויקט, לוחצים על סמל האפשרויות הנוספות לצד המשאב של מאזן העומסים ובוחרים באפשרות כותרת חתומה JWT Audience. בתיבת הדו-שיח Signed Header JWT שמופיעה, מוצגת התביעה aud של המשאב שנבחר.
כדי להשתמש ב-ה-CLI של gcloud כדי לקבל את ערכי המחרוזת של aud, אתם צריכים לדעת את מזהה הפרויקט. מזהה הפרויקט מופיע בכרטיס Project info במסוףGoogle Cloud . אחרי שמוצאים אותו, מריצים את הפקודות שצוינו לכל ערך.
מספר הפרויקט
כדי לקבל את מספר הפרויקט באמצעות ה-CLI של gcloud, מריצים את הפקודה הבאה:
gcloud projects describe PROJECT_ID
הפקודה מחזירה פלט כמו זה:
createTime: '2016-10-13T16:44:28.170Z' lifecycleState: ACTIVE name: project_name parent: id: '433637338589' type: organization projectId: PROJECT_ID projectNumber: 'PROJECT_NUMBER'
מזהה השירות
כדי לקבל את מזהה השירות באמצעות ה-CLI של gcloud, מריצים את הפקודה הבאה:
gcloud compute backend-services describe SERVICE_NAME --project=PROJECT_ID --global
הפקודה מחזירה פלט כמו זה:
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
אחזור זהות המשתמש
אם כל האימותים הקודמים בוצעו בהצלחה, מאחזרים את זהות המשתמש. ה-payload של טוקן המזהה מכיל את פרטי המשתמש הבאים:
| זהות המשתמש ב-payload של טוקן המזהה | ||
|---|---|---|
sub |
נושא |
המזהה הייחודי והקבוע של המשתמש. משתמשים בערך הזה במקום בכותרת x-goog-authenticated-user-id.
|
email |
כתובת האימייל של המשתמש | כתובת האימייל של המשתמש.
|
הקוד הבא הוא קוד לדוגמה לאבטחת אפליקציה באמצעות כותרות IAP חתומות:
C#
Go
Java
Node.js
PHP
Python
Ruby
בדיקת קוד האימות
אם נכנסים לאפליקציה באמצעות הפרמטרים של השאילתה secure_token_test, IAP יכלול אסימון JWT לא חוקי. כדאי להשתמש באפשרות הזו כדי לוודא שהלוגיקה של אימות ה-JWT מטפלת בכל מקרי הכשל השונים, ולראות איך האפליקציה מתנהגת כשהיא מקבלת JWT לא תקין.
יצירת חריג לבדיקת תקינות
כמו שצוין קודם, בדיקות תקינות של Compute Engine ו-GKE לא משתמשות בכותרות JWT, ו-IAP לא מטפל בבדיקות תקינות. צריך להגדיר את בדיקת התקינות ואת האפליקציה כדי לאפשר גישה לבדיקת התקינות.
הגדרת בדיקת התקינות
אם עדיין לא הגדרתם נתיב לבדיקת התקינות, השתמשו במסוףGoogle Cloud כדי להגדיר נתיב לא רגיש לבדיקת התקינות. חשוב לוודא שהנתיב הזה לא משותף עם משאב אחר.
- נכנסים לדף Health checks במסוף Google Cloud .
כניסה לדף Health checks - לוחצים על בדיקת התקינות שבה משתמשים באפליקציה, ואז לוחצים על Edit.
- בקטע נתיב הבקשה, מוסיפים שם נתיב לא רגיש. כאן מציינים את נתיב כתובת ה-URL שמשמש את Google Cloud לשליחת בקשות לבדיקת תקינות.
אם משמיטים את השדה, בקשת בדיקת התקינות נשלחת אל
/. - לוחצים על Save.
הגדרת אימות ה-JWT
בקוד שמפעיל את שגרת האימות של JWT, מוסיפים תנאי להצגת סטטוס HTTP 200 לנתיב הבקשה של בדיקת התקינות. לדוגמה:
if HttpRequest.path_info = '/HEALTH_CHECK_REQUEST_PATH' return HttpResponse(status=200) else VALIDATION_FUNCTION
אוטומציה של שמירת מפתחות ציבוריים במטמון
המערכת של IAP מחליפה את המפתחות הציבוריים שלה מדי פעם. כדי לוודא שתמיד תוכלו לאמת את ה-JWT של IAP, מומלץ לשמור את המפתחות במטמון כדי להימנע מאחזור שלהם מכתובת ה-URL הציבורית בכל בקשה, ולהפוך את תהליך העדכון של המפתח שנשמר במטמון לאוטומטי. הגישה הזו שימושית במיוחד לאפליקציות שפועלות בסביבה עם מגבלות רשת, כמו היקף שירות של VPC Service Controls.
היקף של VPC Service Controls יכול למנוע גישה ישירה לכתובת ה-URL הציבורית של המפתחות. אם שומרים את המפתחות במטמון בקטגוריה של Cloud Storage, האפליקציות יכולות לאחזר אותם ממיקום בתוך ההיקף של VPC-SC.
ההגדרה הבאה של Terraform פורסת פונקציה ב-Cloud Run, שמאחזרת את המפתחות הציבוריים העדכניים של IAP מ-https://www.gstatic.com/iap/verify/public_key-jwk ומאחסנת אותם בקטגוריה של Cloud Storage. משימה של Cloud Scheduler מפעילה את הפונקציה הזו כל 12 שעות כדי לעדכן את המפתחות.
ההגדרה הזו כוללת את הפריטים הבאים:
- ממשקי Google Cloud API שנדרשים כדי להשתמש ב-Cloud Run ולאחסן מפתחות ולשמור אותם במטמון
- קטגוריה של Cloud Storage לאחסון המפתחות הציבוריים של IAP שאוחזרו
- קטגוריה של Cloud Storage להכנת קוד המקור של פונקציות Cloud Run
- חשבונות שירות לפונקציות Cloud Run ול-Cloud Scheduler עם הרשאות IAM מתאימות
- פונקציית Python לאחזור ולאחסון של מפתחות
- משימה של Cloud Scheduler להפעלת הפונקציה כל 12 שעות
מבנה הספרייה
├── 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
מחליפים את מה שכתוב בשדות הבאים:
-
BUCKET_NAME: השם של הקטגוריה של Cloud Storage -
OBJECT_NAME: שם האובייקט שבו רוצים לאחסן את המפתחות
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" }
מחליפים את מה שכתוב בשדות הבאים:
-
PROJECT_ID: מזהה הפרויקט ב- Google Cloud -
REGION: האזור שבו פורסים את המשאבים, לדוגמהus-central1 -
BUCKET_NAME: השם של הקטגוריה של Cloud Storage שבה מאוחסנים מפתחות IAP -
BUCKET_NAME_FUNCTION: השם של הקטגוריה של Cloud Storage שבה מאוחסן קוד המקור של פונקציות Cloud Run
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
יוצרים קובץ terraform.tfvars כדי לציין את מזהה הפרויקט ולהתאים אישית את שמות הקטגוריות לפי הצורך:
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"
פריסה באמצעות Terraform
- שומרים את הקבצים במבנה הספרייה שמתואר למעלה.
- עוברים לספרייה בטרמינל ומפעילים את Terraform:
terraform init - תכנון השינויים:
terraform plan - מחילים את השינויים:
terraform apply
הפעולה הזו פורסת את התשתית. המשימה של Cloud Scheduler מפעילה את הפונקציה כל 12 שעות, מאחזרת את מפתחות ה-IAP ושומרת אותם ב-gs://BUCKET_NAME/iap_public_keys.jwk כברירת מחדל. עכשיו האפליקציות יכולות לאחזר את המפתחות מהקטגוריה הזו.
מחיקת משאבים
כדי להסיר את המשאבים שנוצרו על ידי Terraform, מריצים את הפקודות הבאות:
gsutil rm -a gs://BUCKET_NAME/** terraform destroy -auto-approve
מחליפים את BUCKET_NAME בקטגוריה של Cloud Storage למפתחות.
אסימוני JWT לזהויות חיצוניות
אם אתם משתמשים ב-IAP עם זהויות חיצוניות, IAP עדיין ינפיק JWT חתום בכל בקשה מאומתת, בדיוק כמו שהוא עושה עם Google Identity. אבל יש כמה הבדלים.
פרטי הספק
כשמשתמשים בזהויות חיצוניות, המטען הייעודי (payload) של ה-JWT יכיל הצהרה בשם gcip. הטענה הזו מכילה פרטי משתמש, כמו כתובת האימייל, כתובת ה-URL של התמונה ומאפיינים נוספים שספציפיים לספק.
הנה דוגמה ל-JWT של משתמש שהתחבר באמצעות פייסבוק:
"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"
}',
השדות email ו-sub
אם משתמש אומת על ידי Identity Platform, השדות email ו-sub של ה-JWT יתחילו במנפיק האסימון של Identity Platform ובמזהה הדייר שנעשה בו שימוש (אם יש כזה). לדוגמה:
"email": "securetoken.google.com/PROJECT-ID/TENANT-ID:demo_user@gmail.com", "sub": "securetoken.google.com/PROJECT-ID/TENANT-ID:gZG0yELPypZElTmAT9I55prjHg63"
שליטה בגישה באמצעות sign_in_attributes
ב-IAM אין תמיכה בזהויות חיצוניות, אבל אפשר להשתמש בהצהרות שמוטמעות בשדה sign_in_attributes כדי לשלוט בגישה. לדוגמה, נניח שמשתמש נכנס באמצעות ספק 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"
}
אפשר להוסיף לאפליקציה לוגיקה שדומה לקוד הבא כדי להגביל את הגישה למשתמשים עם תפקיד חוקי:
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.
}
אתם יכולים לגשת למאפייני משתמש נוספים מספקי SAML ו-OIDC של Identity Platform באמצעות הטענה הנכונה המקוננת gcipClaims.gcip.firebase.sign_in_attributes.
מגבלות על גודל ההצהרות של ספק הזהויות (IdP)
אחרי שמשתמש נכנס באמצעות Identity Platform, מאפייני המשתמש הנוספים מועברים ל-payload של אסימון המזהה של Identity Platform ללא שמירת מצב, שמועבר באופן מאובטח ל-IAP. לאחר מכן, IAP ינפיק קובץ Cookie אטום משלו בלי שמירת מצב, שגם מכיל את אותן הצהרות. IAP ייצור את כותרת ה-JWT החתומה על סמך תוכן קובץ ה-cookie.
כתוצאה מכך, אם סשן מתחיל עם הרבה הצהרות, הוא עלול לחרוג מהגודל המקסימלי המותר של קובצי Cookie, שהוא בדרך כלל כ-4KB ברוב הדפדפנים. הפעולה הזו תגרום לכך שפעולת הכניסה תיכשל.
חשוב לוודא שרק ההצהרות הנחוצות מופצות במאפייני ה-SAML או ה-OIDC של ה-IdP. אפשרות נוספת היא להשתמש בפונקציות חסימה כדי לסנן את ההצהרות שלא נדרשות לבדיקת ההרשאה.
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,
};
}
});