פתרון בעיות באיחוד שירותי אימות הזהויות של כוח העבודה

בדף הזה מוסבר איך לפתור בעיות נפוצות באיחוד שירותי אימות הזהות של כוח עבודה.

בדיקת התשובה שחוזרת מה-IdP

בקטע הזה מוסבר איך לבדוק את התשובה מספק הזהויות (IdP) כדי לפתור את הבעיות שמפורטות בהמשך.

כניסה באמצעות דפדפן

כדי לבדוק את התשובה שחוזרת מה-IdP, יוצרים קובץ HAR באמצעות כלי לבחירתכם. לדוגמה, אפשר להשתמש ב-HAR Analyzer מארגז הכלים של Google Admin, שמכיל הוראות ליצירת קובץ HAR ואת הכלים הדרושים כדי להעלות אותו ולנתח אותו.

SAML

כדי לבדוק את התשובה שחוזרת מה-IdP של SAML:

  1. מאתרים בקובץ ה-HAR את הערך של הפרמטר SAMLResponse של הבקשה, שמתועד בכתובת ה-URL שמכילה את הנתיב /signin-callback.
  2. מפענחים אותו באמצעות כלי לבחירתכם. לדוגמה, תוכלו להשתמש בכלי Encode/Decode מארגז הכלים של Google Admin.

OIDC

כדי לבדוק את התשובה שחוזרת מה-IdP של OIDC, פועלים לפי השלבים הבאים. הגישה הזו לא פועלת עם זרימת קוד.

  1. מאתרים בקובץ ה-HAR את הערך של הפרמטר id_token של הבקשה, שמתועד בכתובת ה-URL שמכילה את הנתיב /signin-callback.
  2. מפענחים אותו באמצעות כלי לניפוי באגים של JWT לבחירתכם.

‫CLI של gcloud

כדי לבדוק את התשובה שחוזרת מה-IdP של ה-CLI של gcloud, מעתיקים את תוכן הקובץ שהעברתם לפקודה gcloud iam workforce-pools create-cred-config בדגל --credential-source-file ואז מבצעים את השלבים הבאים:

SAML

מפענחים התשובה שחוזרת מה-IdP של SAML באמצעות כלי לבחירתכם. לדוגמה, תוכלו להשתמש בכלי Encode/Decode מארגז הכלים של Google Admin.

OIDC

מפענחים את התשובה שחוזרת מה-IdP של OIDC באמצעות כלי לניפוי באגים של JWT לבחירתכם.

בדיקת היומנים

כדי לקבוע אם Google Cloud מתקשר עם ספק הזהויות שלכם ולבדוק את פרטי העסקה, אתם יכולים לבדוק את היומנים של Cloud Audit Logs.

דוגמאות ליומנים מופיעות במאמר דוגמאות ליומני ביקורת.

שגיאות בניהול של מאגר כוח עבודה והספקים שלו

בקטע הזה מפורטות הצעות לתיקון שגיאות נפוצות שעשויות לקרות כשאתם מנהלים מאגרים וספקים.

שגיאות כלליות במיפוי מאפיינים

כדי לפתור בעיות במיפוי מאפיינים של ספק מאגר זהויות של כוח העבודה:

  • בודקים את המאפיינים, שנקראים גם הצהרות, בהגדרות של ה-IdP. בודקים איך מיפוי המאפיינים ממיר מאפיינים של IdP למאפיינים של Google Cloudואיך התנאים מעריכים את המאפיינים האלה כדי לאפשר או לדחות גישה במסוף Google Cloud .

    1. חשוב לוודא שהקצו לכם את התפקיד IAM Workforce Pool Editor (roles/iam.workforcePoolEditor).
    2. כדי להפעיל את תהליך הכניסה מבוסס-הדפדפן לאיחוד שירותי אימות הזהות של כוח עבודה, מוסיפים את https://auth.cloud.google/signin-callback/locations/global/workforcePools/POOL_ID/providers/PROVIDER_ID לרשימת ה-URI להפניה אוטומטית המותרים ב-IdP.

    3. במסוף Google Cloud , עוברים אל Workforce Identity Pools.

      כניסה לדף Workforce Identity Pools
    4. ברשימת המאגרים, לוחצים על שם המאגר שרוצים לאמת.
    5. בדף פרטי מאגר כוח העבודה, לוחצים על השם של ספק הזהויות שרוצים לאמת.
    6. בדף פרטי הספק, לוחצים על איתור באגים של טוקן ספק הזהויות.
    7. בתיבת הדו-שיח Sign in (כניסה), נכנסים ל-IdP בתור משתמש לבדיקה.

    בדף Validate your provider attributes (אימות מאפייני הספק) מוצגים המאפיינים הממופים והתוצאה של תנאי המאפיין.

    בקטע Mapped attributes from your IdP token (מאפיינים ממופים מהאסימון של ספק ה-IdP) מוצג אופן האכלוס של מאפייני Google, כמו google.subject, מהאסימון של ספק ה-IdP, על סמך הגדרת המיפוי. אם המיפוי שגוי, מופיע סמל שגיאה.

    בקטע תנאי המאפיין מוצגת התוצאה הבוליאנית של התנאי. אם התנאי מקבל את הערך false, הכניסה נחסמת.

    כדי לראות את אסימון הטענה המלא, לוחצים על הצגת האסימון המלא. כאן מוצג אובייקט ה-JSON הגולמי מ-IdP. כדי להפנות למאפיין ברמה העליונה במיפויים, משתמשים בפורמט assertion.PROPERTY_NAME.

    כדי לתקן שגיאות, אפשר לערוך את ההגדרה:

    1. בדף Validate your provider attributes (אימות מאפייני הספק), לוחצים על Edit (עריכה).
    2. מבצעים את השינויים הנדרשים.
    3. כדי להתחיל בדיקה חדשה ולראות את התוצאות המעודכנות, לוחצים על שמירה ואחזור מחדש של טוקן.

  • בודקים את הטוקנים שנוצרו על ידי ספק הזהויות. כדי ללמוד איך ליצור טוקן מה-IdP, צריך לעיין במסמכי התיעוד של הספק.

  • בודקים את הרישום המפורט ביומן הביקורת של איחוד שירותי אימות הזהות של כוח עבודה ביומני הביקורת של Cloud.

רישום מפורט ביומן הביקורת מתעד שגיאות אימות והרשאה לצד טענות שהתקבלו על ידי איחוד שירותי אימות הזהות של כוח עבודה.

אפשר להפעיל יומני ביקורת מפורטים כשיוצרים את הספק של מאגר הזהויות של כוח העבודה. כדי להפעיל יומני ביקורת מפורטים, מוסיפים את הדגל --detailed-audit-logging כשיוצרים את הספק של מאגר הזהויות של כוח העבודה.

ההרשאה נדחתה

השגיאה הזו מתרחשת כשמשתמש שמנסה להגדיר איחוד שירותי אימות הזהות של כוח העבודה לא קיבל את התפקיד 'אדמין של מאגר זהויות של כוח עבודה' (roles/iam.workforcePoolAdmin) ב-IAM.

INVALID_ARGUMENT: Missing OIDC web single sign-on config

השגיאה הבאה מתקבלת כשיוצרים ספק של מאגר הזהויות של כוח עבודה של OIDC מבלי להגדיר את השדות web-sso-response-type ו-web-sso-assertion-claims-behavior:

ERROR: (gcloud.iam.workforce-pools.providers.create-oidc) INVALID_ARGUMENT: Missing OIDC web single sign-on config.

כדי לפתור את השגיאה, צריך לבצע את השלבים בקטע איך יוצרים ספק כדי להגדיר את השדות באופן תקין כשיוצרים את הספק של מאגר הזהויות של כוח עבודה ב-OIDC.

הייתה חריגה ממגבלת הקצב. צריך לנסות שוב מאוחר יותר

השגיאה הזו מתקבלת כשמגיעים למכסת השימוש במשאבים של מאגר כוח העבודה. כדי לבקש הגדלה של המכסה, צריך לפנות אל Google Cloud נציג החשבון.

שגיאות בכניסה לחשבון

בקטע הזה מפורטות הצעות לתיקון שגיאות נפוצות שעשויות להתרחש כשמשתמש של איחוד שירותי אימות הזהות של כוח עבודה נכנס לחשבון.

שגיאות נפוצות בכניסה לחשבון

השגיאה: The given credential is rejected by the attribute condition

השגיאה הזו מתקבלת כשתנאי המאפיין שצוין בספק של מאגר הזהויות של כוח עבודה לא מתקיים.

לדוגמה, שימו לב לתנאי המאפיין הבא:

SAML

'gcp-users' in assertion.attributes.groups

OIDC

'gcp-users' in assertion.groups

במקרה הזה, השגיאה תופיע אם רשימת הקבוצות שספק הזהויות (IdP) שלכם שלח במאפיין groups לא מכילה את הערך gcp-users.

כדי לפתור את השגיאה, מבצעים את השלבים הבאים:

  1. מתארים את הספק שדרכו בוצעה הכניסה ובודקים שהמאפיין attributeCondition מכיל ערך תקין. מידע על הפעולות שאפשר לבצע על תנאים, זמין במאמר הגדרת שפה.

  2. פועלים לפי השלבים המפורטים במאמר איך בודקים את התשובה שחוזרת מה-IdP כדי לראות את המאפיינים שחוזרים מה-IdP ולוודא שהפורמט של התנאי של המאפיין תקין ומדויק.

  3. נכנסים למסוף Admin ב-IdP ובודקים אם מאפייני ה-IdP שצוינו בתנאי המאפיין מוגדרים בצורה נכונה. אם יש צורך, כדאי להיעזר במסמכי התיעוד של הספק.

השגיאה: The mapped attribute must be of type STRING

הודעת השגיאה הזו מתקבלת לספק של מאגר הזהויות של כוח עבודה ב-SAML במקרה שהמאפיין שצוין בהודעת השגיאה אמור להכיל ערך של מחרוזת יחידה, אבל הוא ממופה למאפיין מסוג רשימה במיפוי המאפיינים

לדוגמה, אם יש לכם ספק של מאגר זהויות של כוח עבודה ב-SAML עם מיפוי המאפיינים הבא: attribute.role=assertion.attributes.userRole. בטענת הנכוֹנוּת (assertion) של SAML, לכל Attribute יכולים להופיע כמה תגי AttributeValue כמו בדוגמה הבאה. במקרה כזה, כל המאפיינים של SAML נחשבים לרשימות, כך שהערך של המאפיין assertion.attributes.userRole נחשב לרשימה.

<saml:Attribute Name="userRole">
    <saml:AttributeValue>
      security-admin
    </saml:AttributeValue>
    <saml:AttributeValue>
      user
    </saml:AttributeValue>
</saml:Attribute>

בדוגמה הזאת, יכול להיות שתתקבל השגיאה הבאה:

The mapped attribute 'attribute.role' must be of type STRING

כדי לפתור את השגיאה, מבצעים את השלבים הבאים:

  1. מתארים את הספק שדרכו בוצעה הכניסה ומציינים את מאפיין ה-IdP שמוגדר במיפוי attributeMapping. בודקים את המאפיין אל מול המאפיין שמוצג בהודעת השגיאה. בדוגמה שלמעלה, מאפיין ה-IdP שנקרא userRole ממופה למאפיין role, והמאפיין role הוא זה שמופיע בדוגמה של השגיאה.

  2. כשמעדכנים את מיפוי המאפיינים, חשוב לשים לב לדברים הבאים:

    • אם השגיאה נגרמת בגלל מאפיין שמכיל ערכים של רשימה, צריך למצוא מאפיין חלופי ויציב שיכול להכיל ערך של מחרוזת. לאחר מכן, מכניסים את המאפיין הזה למיפוי המאפיינים על ידי הפנייה לפריט הראשון ברשימה. למשל, בדוגמה שלמעלה, אם בחרתם את המאפיין myRole כמאפיין החלופי שמכיל ערך בודד ב-IdP, כך ייראה מיפוי המאפיינים:

      attribute.role=assertion.attributes.myRole[0]

    • לחלופין, אם אתם יודעים שהמאפיין מכיל ערך יחיד, מפנים במיפוי המאפיינים את הפריט הראשון ברשימה. למשל, בדוגמה שלמעלה, אם המאפיין userRole מכיל רק תפקיד אחד, תוכלו להשתמש במיפוי הבא:

      attribute.role=assertion.attributes.userRole[0]

    • במאמר הגדרת שפה תוכלו לקרוא איך לחלץ מזהה יציב בעל ערך יחיד מהרשימה כדי לעדכן את מיפוי המאפיינים בהתאם.

בקטע בדיקת התשובה שחוזרת מה-IdP תוכלו לראות פרטים לגבי התשובה שחוזרת מה-IdP.

השגיאה: Could not obtain a value for google.subject from the given credential

השגיאה הזו מתקבלת כשאי אפשר למפות את ההצהרה הנדרשת google.subject באמצעות מיפוי המאפיינים שהגדרתם בהגדרות של הספק של מאגר הזהויות של כוח עבודה.

כדי לפתור את השגיאה, מבצעים את השלבים הבאים:

  1. מתארים את הספק ובודקים את המיפוי attributeMapping. מאתרים את המיפוי שהגדרתם ל-google.subject. אם המיפוי שגוי, עליכם לעדכן את ההגדרות של הספק של מאגר הזהויות של כוח עבודה.

  2. בקטע בדיקת התשובה שחוזרת מה-IdP תוכלו לראות פרטים לגבי התשובה שחוזרת מה-IdP. בתשובה שחוזרת מה-IdP, בודקים את הערך של המאפיין שממופה ל-google.subject במיפוי המאפיינים.

    אם הערך ריק או שגוי, מתחברים למסוף Admin של הספק ובודקים את הגדרת המאפיינים. לכל מאפיין, בודקים אם למשתמש הרלוונטי יש את הנתונים התואמים ב-IdP. מעדכנים ב-IdP את ההגדרות של המאפיינים או את פרטי המשתמש בהתאמה.

  3. מנסים להיכנס שוב.

הגודל של מאפיינים ממופים חורג מהמגבלה

השגיאה הבאה מתרחשת כשמשתמש מאוחד מנסה להיכנס:

The size of the entire mapped attributes exceeds the 16 KB limit.

כדי לפתור את הבעיה, צריך לבקש מהאדמין של ה-IdP להקטין את מספר המאפיינים שה-IdP שולח. ה-IdP צריך רק להפיק מאפיינים שנדרשים כדי לאחד משתמשים עם Google Cloud. מידע נוסף על מגבלות של מיפוי מאפיינים זמין במאמר מיפוי מאפיינים.

לדוגמה, אם ספק הזהויות (IdP) שלכם פולט מספר גדול של google.groups שהם מאפיינים ממופים בספק של מאגר הזהויות של כוח עבודה, ניסיון כניסה עלול להיכשל. צריך לבקש מהאדמין להגביל את מספר הקבוצות שספק הזהויות (IdP) שולח.

מספר הקבוצות חורג מהמגבלה

השגיאה הבאה מתרחשת כשמשתמש מאוחד מנסה להיכנס:

The current count of GROUPS_COUNT mapped attribute google.groups exceeds the GROUPS_COUNT_LIMIT count limit. Either modify your attribute mapping or the incoming assertion to produce a mapped attribute that has fewer than GROUPS_COUNT_LIMIT groups.

השגיאה הזו כוללת את הערכים הבאים:

  • ‫GROUPS_COUNT: מספר הקבוצות שה-IdP מפיק

  • ‫GROUPS_COUNT_LIMIT: Google Cloud's count limit for groups

השגיאה הזו מתרחשת כשמספר הקבוצות שהונפקו על ידי ספק הזהויות חורג מהמגבלה שלGoogle Cloud. קבוצות ממופות ל Google Cloud באמצעות המאפיין google.groups.

כדי לפתור את הבעיה, צריך לבקש מהאדמין להקטין את מספר הקבוצות שספק הזהויות (IdP) שולח. ספק ה-IdP צריך להנפיק רק קבוצות שמשמשות לאיחוד משתמשים אל Google Cloud. מידע נוסף על מגבלות שקשורות לקבוצות זמין במאמר בנושא מיפוי מאפיינים.

לא נמצא דייר SCIM

השגיאה הזו מתרחשת כשמשתמש מנסה להיכנס באמצעות פלאגין שמתממשק עם שירותים חיצוניים של מאגר זהויות של כוח עבודה שמוגדר לשימוש ב-SCIM, אבל לא מוגדר דייר (tenant) SCIM עבור הפלאגין שמתממשק עם שירותים חיצוניים הזה.

במצב כזה, המשתמשים מקבלים את השגיאה הבאה כשהם מנסים להיכנס:

There was an issue signing in with your identity provider.

כדי לפתור את השגיאה, מבצעים את הפעולות הבאות:

  1. הגדרת דייר וטוקן של SCIM ב- Google Cloud
  2. מקשרים את הספק לדייר SCIM.

השגיאה: ‎400. That's an error

השגיאה הזו מתקבלת כשהבקשה לא התקבלה כמצופה או שהפורמט שלה היה שגוי.

כדי לפתור את השגיאה, מבצעים את השלבים הבאים:

  1. פועלים לפי השלבים המפורטים בקטע הדרכת המשתמשים על דרכי הכניסה כדי לוודא שמנסים להיכנס בצורה הנכונה.

  2. משווים בין ההגדרות בספק הזהויות של כוח עבודה לבין ההגדרות ב-IdP.

שגיאות בכניסה לחשבון שקשורות למאפיינים נוספים

בקטע הזה מפורטות הצעות לתיקון שגיאות שמתרחשות כשמשתמשים במאפיינים נוספים.

הכניסה נכשלת כשמוגדרים מאפיינים נוספים

אם הגדרתם מאפיינים נוספים, כל בעיה בהגדרה – כמו מזהה לקוח שגוי, סוד לקוח שגוי או URI של מנפיק שגוי – תגרום לניסיון הכניסה להיכשל.

כדי לפתור את השגיאה, מבצעים את השלבים הבאים:

  1. מתארים את הספק ומוודאים שמזהה הלקוח ו-URI המנפיק נכונים.
  2. מוודאים שהסוד של הלקוח תקין ושהתוקף שלו לא פג.
  3. בספק הזהויות, מוודאים שלאפליקציה יש את ההרשאות הנדרשות.

המערכת מתעלמת מקבוצות מטענת נכונות (assertion) של SAML או OIDC

כשמגדירים מאפיינים נוספים, איחוד שירותי אימות הזהות של כוח העבודה מתעלם מכל מידע קבוצתי שמופיע ישירות בהצהרות SAML או OIDC. במקום זאת, היא משתמשת רק בקבוצות שאוחזרו באמצעות הערוץ האחורי (לדוגמה, באמצעות Microsoft Graph API).

אם המשתמשים לא רואים את הקבוצות הרצויות, צריך לוודא שהקבוצות מאוחזרות בצורה נכונה באמצעות הערוץ האחורי, ושהגדרתם נכון את מסנני המאפיינים.

שגיאות OIDC בכניסה

בקטע הזה מפורטות הצעות לתיקון שגיאות ספציפיות ל-OIDC שעשויות להתרחש כשמשתמש של איחוד שירותי אימות הזהויות של כוח עבודה נכנס לחשבון.

שגיאה בחיבור למנפיק פרטי הכניסה

השגיאה הזו מתקבלת כשספק של מאגר זהויות של כוח עבודה ב-OIDC לא יכול לגשת למסמך הגילוי של OIDC או למזהה ה-URI של מפתחות ה-JWK.

כדי לפתור את השגיאה, מבצעים את השלבים הבאים:

  1. מתארים את הספק ובודקים את הערך של issuerUri. מצרפים את המחרוזת /.well-known/openid-configuration ל-URI של המנפיק כדי ליצור את כתובת ה-URL של מסמך הגילוי. לדוגמה, אם הערך של issuerUri הוא https://example.com, כתובת ה-URL של מסמך הגילוי תהיה https://example.com/.well-known/openid-configuration.

  2. פותחים את כתובת ה-URL של מסמך Discovery בחלון גלישה פרטית.

    1. אם אתם לא מצליחים להגיע לכתובת ה-URL או שהדפדפן מציג שגיאה מסוג 404, צריך לעיין במסמכי התיעוד של הספק כדי לזהות את ה-URI הנכון של המנפיק. אם יש צורך, מעדכנים את הערך של issuerUri בספק של מאגר הזהויות של כוח העבודה.

      אם ה-IdP שלכם פועל באופן מקומי, צריך לעיין במסמכי התיעוד של הספק כדי להקצות לו גישה לאינטרנט.

    2. אם כתובת ה-URL נפתחת כראוי, בודקים את התנאים הבאים:

      1. מוודאים שכתובת ה-URL לא מבצעת יותר מדי הפניות אוטומטיות לפני הצגת מסמך Discovery. אם כן, עליכם להתייעץ עם האדמין של ה-IdP שלכם כדי לפתור את הבעיה.
      2. בודקים את זמני התגובה של ה-IdP. במקרה הצורך כדאי להתייעץ עם האדמין של ה-IdP כדי לקצר את זמן האחזור.
      3. מוודאים שמסמך Discovery שנפתח הוא בפורמט JSON.

      4. מאתרים את השדה jwks_uri בקובץ ה-JSON.

        1. מוודאים שגם כתובת ה-URL המשויכת נפתחת.
        2. מוודאים שכתובת ה-URL עומדת בתנאים שמתוארים למעלה במדריך הזה.

    3. מנסים להיכנס שוב.

שגיאות SAML בכניסה

בקטע הזה מפורטות הצעות לתיקון שגיאות ספציפיות ל-SAML שעשויות להתרחש כשמשתמש של איחוד שירותי אימות הזהות של כוח עבודה נכנס לחשבון.

השגיאה: Failed to verify the signature in SAMLResponse

הודעת השגיאה הזו מתקבלת בספק של מאגר זהויות של כוח עבודה ב-SAML במקרה שאי אפשר לאמת את החתימה בתשובה שחוזרת מה-IdP באמצעות אישורי X.509 שסופקו ב-XML של המטא-נתונים של ה-IdP, שהגדרתם בספק של מאגר הזהויות של כוח עבודה. סיבה נפוצה לשגיאה הזאת יכולה להיות שאישור האימות ב-IdP הוחלף, אבל לא עדכנתם את קובץ ה-XML של המטא-נתונים של ה-IdP בהגדרות של הספק של מאגר הזהויות של כוח עבודה.

כדי לפתור את השגיאה, מבצעים את השלבים הבאים:

  1. אופציונלי: פועלים לפי השלבים שמפורטים בקטע בדיקת התשובה שחוזרת מה-IdP כדי לאתר בתשובה שחוזרת מה-IdP את המאפיין X509Certificate. מתארים את הספק שדרכו נכנסתם לחשבון, ובודקים את ערך שדה האישור X509Certificate שמופיע בערך שמועבר ב-idpMetadataXml כפי שמוגדר בספק של מאגר הזהויות של כוח עבודה. משווים בין האישור הזה לבין האישור שמופיע בתשובה שחוזרת מה-IdP. האישורים צריכים להיות תואמים.

  2. מתחברים למסוף Admin של ה-IdP ומורידים את ה-XML העדכני של המטא-נתונים.

  3. מעדכנים את ה-XML של המטא-נתונים של ה-IdP שהורדתם בהגדרות של הספק של מאגר הזהויות של כוח עבודה.

  4. מנסים להיכנס שוב.

השגיאה: Recipient in SAML assertion is not set to the correct ACS URL

הודעת השגיאה הזו מתקבלת בספק של מאגר הזהויות של כוח עבודה ב-SAML כשהתשובה שחוזרת מה-IdP מכילה ערך שגוי בשדה Recipient לתג SubjectConfirmationData.

כדי לפתור את השגיאה הזו, מעדכנים את השדה Recipient URL או Redirect URL או את השדה המקביל בהגדרות של ה-IdP, כך שישתמש בכתובת ה-URL להפניה אוטומטית שמתוארת במאמר הגדרת כתובות URL להפניה אוטומטית ב-IdP, ומנסים להיכנס שוב.

פועלים לפי השלבים שמפורטים בקטעבדיקת התשובה שחוזרת מה-IdP כדי לוודא שהשדה Recipient שחזר בתשובה של ה-IdP תקין.

לדוגמה, לספק של מאגר הזהויות של כוח העבודה locations/global/workforcePools/example-pool/providers/example-provider, השדה Recipient שמכיל את כתובת ה-URL להפניה אוטומטית מופיע בתשובה שחוזרת מה-IdP של SAML באופן הבא:

<SubjectConfirmationData Recipient="https://auth.cloud.google/signin-callback/locations/global/workforcePools/example-pool/providers/example-provider"

השגיאה: SAMLResponse destination does not match RP callback URL

הודעת השגיאה הזו מתקבלת בספק של מאגר הזהויות של כוח עבודה ב-SAML כשהתשובה שחוזרת מה-IdP מכילה ערך שגוי בשדה Destination לתג Response.

כדי לפתור את השגיאה הזו, מעדכנים את השדה Destination URL או Redirect URL או את השדה המקביל בהגדרות של ה-IdP, כך שישתמש בכתובת ה-URL להפניה אוטומטית שמתוארת במאמר הגדרת כתובות URL להפניה אוטומטית ב-IdP.

פועלים לפי השלבים שמפורטים בקטעבדיקת התשובה שחוזרת מה-IdP כדי לוודא שהשדה Destination שחזר בתשובה של ה-IdP תקין.

לדוגמה, לספק של מאגר הזהויות של כוח העבודה locations/global/workforcePools/example-pool/providers/example-provider, השדה Destination שמכיל את כתובת ה-URL להפניה אוטומטית מופיע בתשובה שחוזרת מה-IdP של SAML באופן הבא:

<Response Destination="https://auth.cloud.google/signin-callback/locations/global/workforcePools/example-pool/providers/example-provider"

השגיאה: Invalid assertion: missing or empty NameID

השגיאה הזו מתקבלת כשהשדה NameId חסר בתשובה שהתקבלה מה-IdP של SAML, או שהוא מכיל ערך ריק.

כדי לפתור את השגיאה הזו, תוכלו להיעזר במסמכי התיעוד של ה-IdP כדי להגדיר אותו כך שיעביר את המאפיין NameID, שהוא הנושא של טענת הנכוֹנוּת (assertion) של SAML (בדרך כלל זה המשתמש שאותו מאמתים).

פועלים לפי השלבים שמפורטים בקטעבדיקת התשובה שחוזרת מה-IdP כדי לבדוק את התשובה שחזרה מה-IdP ואת הערך במאפיין NameID.

השגיאה: All <AudienceRestriction>s should contain the SAML RP entity ID

השגיאה הזו מתקבלת כשבתשובה שחוזרת מה-IdP של SAML אין בתגי ה-AudienceRestriction הגדרה של התג Audience עם ערך שמייצג את מזהה הישות ב-SAML של ספק המאגר של כוח עבודה.

כדי לפתור את השגיאה, מבצעים את השלבים הבאים:

  1. תוכלו להיעזר במסמכי התיעוד של ה-IdP כדי להבין איך להגדיר אותו כך שישלח את הקהל בתגי ה-AudienceRestriction שנשלחים בתשובה של SAML. בדרך כלל מגדירים את הקהל על ידי הגדרת השדה Entity ID או Audience בהגדרות של ה-IdP. בקטע SAML במאמר איך יוצרים ספק של מאגר זהויות של כוח עבודה מוסבר מה הערך שצריך להגדיר בשדה SP Entity ID.

  2. לאחר שמעדכנים את ההגדרות ב-IdP, מנסים להיכנס שוב.

פועלים לפי השלבים שמפורטים בקטעבדיקת התשובה שחוזרת מה-IdP כדי לבדוק את התשובה שחזרה מה-IdP ואת הערכים של המאפיינים מסוג AudienceRestriction.

שגיאות בהקצאת הרשאות ובסנכרון של SCIM

בקטע הזה מוסבר איך לפתור בעיות שקשורות להקצאת הרשאות ולסנכרון של SCIM באיחוד שירותי אימות הזהות של כוח העבודה.

נכשל אימות טוקן SCIM‏ (HTTP 401 או 403)

השגיאה הזו מתרחשת כשיומני ספק הזהויות (IdP) מדווחים על כשלים באימות (HTTP 401 Unauthorized או HTTP 403 Forbidden). סיבות נפוצות לכך:

  • חסר טוקן SCIM, הטוקן לא תקין או שתוקפו פג.
  • אסימון ה-SCIM מכיל רווחים מיותרים.
  • בבקשה חסרה הכותרת Authorization: Bearer <TOKEN>.
  • אין מספיק הרשאות בטוקן SCIM.

כדי לפתור את הבעיה:

  1. בהגדרת ההקצאה של ה-IdP, מוודאים שאסימון ה-SCIM זהה לאסימון הסודי שנוצר ב- Google Cloud , ללא רווחים מיותרים.

  2. אם הטוקן אבד או לא תקין, צריך ליצור טוקן SCIM חדש:

    gcloud iam workforce-pools providers scim-tenants tokens create SCIM_TOKEN_ID \
    --workforce-pool="WORKFORCE_POOL_ID" \
    --provider="PROVIDER_ID" \
    --scim-tenant="SCIM_TENANT_ID" \
    --location="global"

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SCIM_TOKEN_ID: מזהה לאסימון SCIM החדש.
    • ‫WORKFORCE_POOL_ID: המזהה של מאגר הזהויות של כוח העבודה.
    • ‫PROVIDER_ID: המזהה של ספק מאגר כוח העבודה.
    • ‫SCIM_TENANT_ID: המזהה של דייר SCIM.

  3. מעדכנים את אסימון הסודיות בהגדרות של ספק הזהויות.

חריגה ממגבלת הקצב (HTTP 429 Too Many Requests)

השגיאה הזו מתרחשת כששיעורי הבקשות של IdP חורגים מהמכסה של דייר SCIM. כברירת מחדל, בקשות כתיבה וקריאה מוגבלות ל-3,000 בקשות לדקה לכל דייר SCIM לכל ארגון, שזה שווה ערך ל-50 שאילתות לשנייה (QPS). מידע נוסף מופיע במאמר בנושא מכסות ומגבלות.

כדי לפתור את הבעיה:

  1. בודקים שקצב הבקשות לסנכרון של ספק ה-IdP נמצא בתוך מגבלות המכסה.
  2. במסוף Google Cloud , עוברים אל IAM & Admin > Quotas ומסננים לפי iamscim.googleapis.com כדי לעקוב אחרי השימוש במכסה.
  3. אם אתם צריכים תפוקה גבוהה יותר, אתם יכולים לבקש הגדלה של המכסה במסוף Google Cloud .

יצירת דייר SCIM נכשלת

השגיאה הזו מתרחשת כשהפקודה gcloud iam workforce-pools providers scim-tenants createנכשלת.

הסיבות הנפוצות לכך הן:

  • כבר קיים דייר SCIM במאגר כוח העבודה. כל מאגר כוח אדם תומך רק בדייר SCIM אחד.
  • דייר SCIM שנמחק לאחרונה עדיין נמצא בתקופת המחיקה הרכה של 30 יום.
  • אין לכם את התפקיד 'אדמין של מאגר זהויות של כוח עבודה' (roles/iam.workforcePoolAdmin) ב-IAM.
  • הדגל --claim-mapping מכיל ביטויים של Common Expression Language ‏(CEL) שלא נתמכים.

כדי לפתור את הבעיה:

  1. מוודאים שיש לכם את התפקיד 'אדמין של מאגר זהויות של כוח עבודה ב-IAM' (roles/iam.workforcePoolAdmin).

  2. כדי לבדוק אם דייר כבר קיים, מציגים רשימה של דיירים קיימים של SCIM:

    gcloud iam workforce-pools providers scim-tenants list \
    --workforce-pool="WORKFORCE_POOL_ID" \
    --provider="PROVIDER_ID" \
    --location="global"

    מחליפים את מה שכתוב בשדות הבאים:

    • WORKFORCE_POOL_ID: המזהה של מאגר הזהויות של כוח העבודה.
    • PROVIDER_ID: המזהה של ספק מאגר כוח העבודה.

  3. אם דייר שנמחק בעבר נמחק באופן זמני, אפשר למחוק אותו סופית באמצעות הדגל --hard-delete:

    gcloud iam workforce-pools providers scim-tenants delete SCIM_TENANT_ID \
    --workforce-pool="WORKFORCE_POOL_ID" \
    --provider="PROVIDER_ID" \
    --location="global" \
    --hard-delete

    מחליפים את SCIM_TENANT_ID במזהה של דייר SCIM.

  4. מוודאים ש---claim-mapping משתמש רק בביטויי CEL נתמכים. מידע נוסף זמין במאמר מיפוי של אסימונים ומאפייני SCIM.

יצירת טוקן SCIM נכשלת

השגיאה הזו מתרחשת כשהפקודה gcloud iam workforce-pools providers scim-tenants tokens createנכשלת.

הסיבות הנפוצות לכך הן:

  • בדייר SCIM כבר יש שני אסימוני SCIM, שזה המספר המקסימלי.
  • אין לכם את התפקיד 'אדמין של מאגר זהויות של כוח עבודה' (roles/iam.workforcePoolAdmin) ב-IAM.

כדי לפתור את הבעיה:

  1. מוודאים שיש לכם את התפקיד 'אדמין של מאגר זהויות של כוח עבודה ב-IAM' (roles/iam.workforcePoolAdmin).

  2. כדי לבדוק אם הגעתם למגבלה של שני אסימוני SCIM, מריצים את הפקודה הבאה כדי להציג את האסימונים הקיימים:

    gcloud iam workforce-pools providers scim-tenants tokens list \
    --workforce-pool="WORKFORCE_POOL_ID" \
    --provider="PROVIDER_ID" \
    --scim-tenant="SCIM_TENANT_ID" \
    --location="global"

    מחליפים את מה שכתוב בשדות הבאים:

    • WORKFORCE_POOL_ID: המזהה של מאגר הזהויות של כוח העבודה.
    • PROVIDER_ID: המזהה של ספק מאגר כוח העבודה.
    • ‫SCIM_TENANT_ID: המזהה של דייר SCIM.

  3. אם כבר יש לדייר SCIM שני טוקנים, צריך למחוק טוקן לא בשימוש או לא תקין:

    gcloud iam workforce-pools providers scim-tenants tokens delete SCIM_TOKEN_ID \
    --workforce-pool="WORKFORCE_POOL_ID" \
    --provider="PROVIDER_ID" \
    --scim-tenant="SCIM_TENANT_ID" \
    --location="global"

    מחליפים את SCIM_TOKEN_ID במזהה של אסימון SCIM שרוצים למחוק.

  4. אחרי שמוחקים את הטוקן, מנסים שוב ליצור את טוקן ה-SCIM החדש.

קונפליקט במיפוי מאפיינים כפולים (HTTP 409 Conflict)

השגיאה הזו מתרחשת כשביומנים של ספק הזהויות (IdP) מופיעה שגיאה HTTP 409 Conflict במהלך הסנכרון, כי ספק הזהויות שולח ערכים כפולים של google.subject או google.group, או ערכים לא ייחודיים של userName או displayName.

כדי לפתור את הבעיה:

  1. במסוף Admin של ה-IdP, מוודאים שהמאפיינים שממופים ל-google.subject ול-google.group יוצרים ערכים לא חופפים.
  2. מוודאים שלכל משתמש יש userName ייחודי ולכל קבוצה יש displayName ייחודי.

בקשות PATCH של Microsoft Entra ID נכשלות

השגיאה הזו מתרחשת כשעדכוני משתמשים או בקשות PATCH מ-Microsoft Entra ID נכשלים כי בכתובת ה-URL של הדייר חסר פרמטר השאילתה ?aadOptscim062020, שנדרש לבקשות PATCH שתואמות ל-RFC.

כדי לפתור את הבעיה:

  1. ב-Microsoft Entra ID, עוברים לאפליקציה הארגונית ובוחרים באפשרות Provisioning (הקצאת הרשאות) > Manage provisioning (ניהול הקצאת הרשאות) > Admin Credentials (פרטי כניסה של אדמין).

  2. בשדה Tenant URL (כתובת ה-URL של הדייר), מוסיפים את ?aadOptscim062020 ל-URI הבסיסי:

    https://iamscim.googleapis.com/v1alpha1/tenants/SCIM_TENANT_UID?aadOptscim062020

    מחליפים את SCIM_TENANT_UID במזהה הייחודי של הדייר ב-SCIM.

  3. לוחצים על בדיקת החיבור ושומרים את ההגדרות.

הגישה או השיתוף לפי משתמש או קבוצה לא פועלים

הבעיה הזו מתרחשת כשמשתמשים מסונכרנים לא יכולים לגשת למשאבים Google Cloud או כששיתוף של מחברות ב-Gemini Notebook Enterprise או של סוכנים באפליקציית Gemini Enterprise נכשל.

הסיבות הנפוצות לכך הן:

  • כשלים או עיכובים בסנכרון שמתרחשים בשקט מ-IdP.
  • מיפויי תלונות לא עקביים בין הספק (--attribute-mapping) לבין דייר SCIM‏ (--claim-mapping).
  • שינויים ב-IdP במאפיינים שממופים ל-google.subject או ל-google.group. Google Cloud מצפה שהערכים שממופים למאפיינים האלה לא ישתנו.
  • השימוש ב-SCIM לא מופעל לקבוצות אצל הספק.

כדי לפתור את הבעיה:

  1. אימות הסנכרון והחברות: מוודאים שהמשתמשים, הקבוצות והחברות בקבוצות סונכרנו בהצלחה אל Google Cloud:

    • אימות סנכרון המשתמשים:

      curl -G -H "Authorization: Bearer SCIM_TOKEN" \
  "https://iamscim.googleapis.com/v1alpha1/tenants/SCIM_TENANT_UID/Users" \
  --data-urlencode 'filter=userName eq "USER_NAME"'

    • אימות של סנכרון קבוצות:

      curl -G -H "Authorization: Bearer SCIM_TOKEN" \
  "https://iamscim.googleapis.com/v1alpha1/tenants/SCIM_TENANT_UID/Groups" \
  --data-urlencode 'filter=displayName eq "GROUP_NAME"'

    • אימות החברות בקבוצה: אישור שמשתמש הוא חבר בקבוצה:

      curl -G -H "Authorization: Bearer SCIM_TOKEN" \
  "https://iamscim.googleapis.com/v1alpha1/tenants/SCIM_TENANT_UID/Groups" \
  --data-urlencode 'filter=id eq "GROUP_ID" and members eq "USER_ID"'

      אם המשתמש חבר בקבוצה, התשובה היא totalResults: 1. אם המשתמש לא חבר בקבוצה, התשובה היא totalResults: 0.

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SCIM_TOKEN: אסימון הסוד של SCIM.
    • ‫SCIM_TENANT_UID: המזהה הייחודי של דייר SCIM.
    • ‫USER_NAME: שם המשתמש של המשתמש המסונכרן.
    • ‫GROUP_NAME: השם המוצג של הקבוצה המסונכרנת.
    • ‫GROUP_ID: מזהה ה-SCIM של הקבוצה המסונכרנת, שמוחזר בשדה id של התגובה לשאילתת הקבוצה.
    • ‫USER_ID: מזהה SCIM של המשתמש שסונכרן, מוחזר בשדה id של התגובה לשאילתת המשתמש.

  2. בדיקת מיפויי הטענות: מוודאים שהמאפיין שממופה ל-google.subject אצל הספק (לדוגמה, google.subject=assertion.email.lowerAscii()) תואם לזהות שממופה ב-SCIM tenant (לדוגמה, google.subject=user.emails[0].value.lowerAscii()). מכיוון שמיפויי הטענות הם קבועים, אם המיפויים לא עקביים, צריך למחוק את ה-SCIM tenant באופן סופי וליצור אותו מחדש עם המיפוי הנכון.

  3. מוודאים שהמזהה לא משתנה: בודקים שהמאפיינים של ספק הזהויות שממופים ל-google.subject ול-google.group לא השתנו. Google Cloudמתייחס לערכים שממופים למאפיינים האלה כמזהים שלא משתנים. אם ערך מאפיין השתנה ב-IdP, צריך לבטל את השינוי ב-IdP, או למחוק באופן סופי את המשתמש או הקבוצה המושפעים מה-IdP וליצור אותם מחדש עם הערך החדש, כדי שהמזהה יתאים למה ש- Google Cloudמצפה.

  4. הפעלת השימוש בקבוצות SCIM: מעדכנים את הספק כדי להפעיל SCIM לקבוצות:

    gcloud iam workforce-pools providers update-oidc PROVIDER_ID \
    --workforce-pool="WORKFORCE_POOL_ID" \
    --location="global" \
    --scim-usage="enabled-for-groups"

    מחליפים את מה שכתוב בשדות הבאים:

    • PROVIDER_ID: המזהה של ספק מאגר כוח העבודה.
    • WORKFORCE_POOL_ID: המזהה של מאגר הזהויות של כוח העבודה.

השינויים שבוצעו בספק הזהות מתעדכנים באיחור או לא מתעדכנים בכלל

הבעיה הזו מתרחשת כשהעדכונים של ספק הזהויות (IdP) לגבי משתמשים, חברות בקבוצות או מחיקות לא מופיעים מיד ב- Google Cloud.

מכיוון ש-SCIM מבוסס על שליחת נתונים, העדכונים תלויים בלוח הזמנים של סנכרון ספק הזהויות. לדוגמה, המערכת של Microsoft Entra ID מסתנכרנת בערך כל 40 דקות.

כדי לפתור את הבעיה:

  1. מחכים למחזור הסנכרון המתוזמן הבא מ-IdP.
  2. כדי להחיל שינויים באופן מיידי, מפעילים סנכרון לפי דרישה במסוף האדמין של ספק הזהויות.

הקצאת הרשאות למשתמש נכשלת בגלל פורמט האימייל

השגיאה הזו מתרחשת כשמשתמשים ספציפיים לא מצליחים להסתנכרן עם Google Cloud, ובדוחות של ספק הזהויות (IdP) מופיעה שגיאת HTTP 400 Bad Request עם שגיאת SCIM invalidValue.

Google Cloud ב-SCIM, לכל משתמש צריכה להיות בדיוק כתובת אימייל אחת לצורכי עבודה. הקצאת ההרשאות תיכשל אם ספק הזהויות ישלח כמה אימיילים או אם האימייל לא יהיה מסוג work.

כדי לפתור את הבעיה, צריך להגדיר את מיפוי המאפיינים של ספק הזהויות כך שישלח רק את כתובת האימייל העיקרית של העבודה.

עדכוני קבוצות נכשלים (לא נתמך HTTP PUT)

השגיאה הזו מתרחשת כשעדכוני קבוצות נכשלים כי הלקוח משתמש ב-HTTP PUT, שלא נתמך. ‫ Google Cloud SCIM API תומך רק ב-HTTP PATCH לעדכוני קבוצות.

כדי לפתור את הבעיה הזו, צריך להגדיר את ה-IdP או את הלקוח המותאם אישית כך שישתמש ב-HTTP PATCH לעדכוני קבוצות.