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

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

לפני שמתחילים

  1. ודאו שיש לכם ארגון מוגדר ב- Google Cloud .

  2. התקינו את ה-CLI של Google Cloud. אחר כך, אתחלו את ה-CLI של Google Cloud באמצעות הפקודה הבאה: 

    gcloud init

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

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

עלויות

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

התפקידים הנדרשים

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

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

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

יצירת מאגר זהויות של כוח העבודה

gcloud

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

gcloud iam workforce-pools create WORKFORCE_POOL_ID \
    --organization=ORGANIZATION_ID \
    --display-name="DISPLAY_NAME" \
    --description="DESCRIPTION" \
    --session-duration=SESSION_DURATION \
    --location=global

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

  • ‫WORKFORCE_POOL_ID: המזהה שבחרתם כדי לייצג את Google Cloud מאגר כוח העבודה. המזהה של המאגר חייב להיות ייחודי באופן גלובלי בכל מאגרי הזהויות של כוח העבודה ב- Google Cloud. מידע על הפורמט של המזהה מופיע בקטע פרמטרים של שאילתה במאמרי העזרה של ה-API.
  • ‫ORGANIZATION_ID: מזהה הארגון (מספרי) של Google Cloud הארגון שלכם במאגר הזהויות של כוח העבודה. מאגרי זהויות של כוח עבודה זמינים בכל הפרויקטים והתיקיות בארגון.
  • ‫DISPLAY_NAME: אופציונלי. השם המוצג של מאגר הזהויות של כוח העבודה.
  • ‫DESCRIPTION: אופציונלי. תיאור של מאגר הזהויות של כוח העבודה.
  • ‫SESSION_DURATION: אופציונלי. משך הסשן, שמוצג כמספר עם התוספת s—לדוגמה, 3600s. משך הסשן קובע לכמה זמן יהיו פעילים אסימוני הגישה, המסוף (איחוד), החיבור לסשן והחיבור ל-CLI של gcloud מהמאגר של כוח העבודה. Google Cloud משך הסשן מוגדר כברירת מחדל לשעה אחת (3,600 שניות). ערך משך הסשן צריך להיות בין 15 דקות (900 שניות) ל-12 שעות (43,200 שניות).

המסוף

כדי ליצור את מאגר הזהויות של כוח העבודה:

  1. במסוף Google Cloud , עוברים לדף Workforce Identity Pools:

    כניסה לדף Workforce Identity Pools

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

  3. לוחצים על Create pool ומבצעים את הפעולות הבאות:

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

    2. אופציונלי: בשדה Description (תיאור), מזינים תיאור של המאגר.

    3. כדי ליצור את מאגר הזהויות של כוח העבודה, לוחצים על Next.

משך הסשן במאגר הזהויות של כוח העבודה הוא שעה (3,600 שניות) כברירת מחדל. משך הסשן קובע לכמה זמן יהיו פעילים אסימוני הגישה, המסוף (איחוד) והחיבור לסשן והחיבור ל-ה-CLI של gcloud מהמאגר של כוח העבודה. Google Cloud אחרי שיוצרים את המאגר, אפשר לעדכן את המאגר כדי להגדיר משך סשן בהתאמה אישית. משך הסשן צריך להיות בין 15 דקות (900 שניות) ל-12 שעות (43,200 שניות).

יצירת שילוב אפליקציית Okta

בקטע הזה מתוארים השלבים ליצירת שילוב של אפליקציית Okta באמצעות מסוף ה-Admin של Okta. פרטים נוספים מופיעים במאמר יצירת שילובים לאפליקציות בהתאמה אישית.

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

למידע נוסף, עיינו במדריך השילוב של OIDC ושל SAML. ההגדרות האישיות הבסיסיות מתוארות בחלק הזה.

OIDC

כדי ליצור שילוב של אפליקציית Okta שעושה שימוש בפרוטוקול OIDC, מבצעים את השלבים הבאים:

  1. נכנסים למסוף Admin של Okta.
  2. עוברים אל Applications > Applications.

  3. כדי להתחיל את הגדרת השילוב של האפליקציה:

    1. לוחצים על Create App Integration.
    2. ב-Sign-in method, בוחרים את OIDC - OpenID Connect.
    3. ב-Application type בוחרים סוג אפליקציה, לדוגמה Web Application.
    4. כדי ליצור את האפליקציה, לוחצים על Next.
    5. בקטע App integration name, מזינים שם לאפליקציה.
    6. בקטע Grant type, מסמנים את תיבת הסימון Implicit (hybrid).

    7. בקטע Implicit (hybrid), בשדה הטקסט, מזינים כתובת URL להפניה אוטומטית. המשתמשים שייכנסו לחשבון יופנו לכתובת ה-URL הזו. אם הוגדרה גישה למסוף (איחוד), צריך להשתמש בפורמט הבא של כתובות URL:

      https://auth.cloud.google/signin-callback/locations/global/workforcePools/WORKFORCE_POOL_ID/providers/WORKFORCE_PROVIDER_ID

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

      • ‫WORKFORCE_POOL_ID: המזהה של מאגר כוח העבודה שיצרתם קודם במדריך.
      • ‫WORKFORCE_PROVIDER_ID: המזהה של ספק הזהויות של כוח העבודה שבחרתם. לדוגמה: okta-oidc-provider. מידע על הפורמט של המזהה מופיע בקטע פרמטרים של שאילתה במאמרי העזרה של ה-API.

    8. מסמנים את התיבה Skip group assignment for now.

    9. כדי לשמור את שילוב האפליקציה, לוחצים על Save.

  4. הקצאה של שילוב אפליקציה למשתמש.

  5. אופציונלי: אם רוצים להוסיף מאפיינים מותאמים אישית לפרופיל משתמש ב-Okta, מבצעים את הפעולות הבאות:

    1. בשדה Data Type, בוחרים את string.
    2. בשדה Display name, מזינים Department.
    3. בשדה Data Type, מזינים department.
    4. כדי לשמור את המיפוי, לוחצים על Save.

    למידע נוסף על הוספת מאפיינים מותאמים אישית, ראו הוספת מאפיינים מותאמים אישית לפרופיל משתמש ב-Okta.

  6. אופציונלי: אם רוצים ליצור מיפויים של המאפיינים שנשלחים באסימון ה-OIDC בDirectory, לוחצים על Profile Editor ומבצעים את הפעולות הבאות:

    1. מוצאים את אפליקציית ה-OIDC שיצרתם קודם במדריך הזה.
    2. לוחצים על Mappings.
    3. בוחרים את הכרטיסייה Okta User to App.
    4. בכרטיסייה Okta User User Profile, בתיבה משולבת זמינה, מזינים department. Okta תבצע השלמה אוטומטית ל-user.department.
    5. כדי לשמור את המיפויים, לוחצים על Save Mappings. לפרטים נוספים, קראו את המאמר הוספת מיפוי של מאפיין.

    למידע נוסף על מיפויים, קראו את המאמר מיפוי של מאפייני Okta למאפייני אפליקציות ב-Profile Editor.

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

    1. אם משתמשים בשרת הרשאות ארגוני, מבצעים את הפעולות הבאות:

      1. עוברים אל Applications > Applications
      2. בוחרים את אפליקציית הלקוח OpenID Connect שיצרתם בשלב מוקדם יותר בחלק הזה.
      3. עוברים לכרטיסייה Sign On.
      4. בחלק OpenID Connect ID Token, לוחצים על Edit.
      5. בחלק Groups claim type, אפשר לבחור באחת מהאפשרויות הבאות:
        • בוחרים Expression.
        • בוחרים Matches regex ומזינים .*.
      6. כדי לשמור את הבקשה לקבוצות משתמשים, לוחצים על Save.

      7. אם רוצים שהמשתמשים ייכנסו באמצעות המסוף (מאוחד) או תהליך כניסה באמצעות הדפדפן ל-CLI של gcloud, צריך לבצע את הפעולות הבאות כשיוצרים את ספק הזהויות של מאגר הזהויות של כוח העבודה, בהמשך מאמרי העזרה האלה:

        1. חשוב להשתמש בהוראות של ה-CLI של gcloud כדי שתוכלו להשתמש בדגל --web-sso-additional-scopes.

        2. כשיוצרים את הספק של מאגר הזהויות של כוח העבודה, מעבירים את groups כהיקף נוסף ב---web-sso-additional-scopes. במקרה כזה, המערכת שולחת בקשה לקבלת טענת הקבוצות מ-Okta במהלך הכניסה.

    2. אם משתמשים בשרת הרשאות בהתאמה אישית, מבצעים את הפעולות הבאות:

      1. במסוף Admin, בתפריט Security בוחרים API.
      2. בוחרים את שרת ההרשאות בהתאמה אישית שרוצים להגדיר.
      3. עוברים לכרטיסייה Claims ולוחצים על Add Claim.
      4. מזינים שם לבקשה. בדוגמה הזו, נותנים את השם groups.
      5. בבקשה, בשדה Include in Token type בוחרים את ID Token ובוחרים Always.
      6. בוחרים את Groups בתור Value type.
      7. בתיבת הסינון הנפתחת, בוחרים את Matches regex ואז מזינים את הביטוי הבא כ-Value: .*
      8. לוחצים על Create.

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

SAML

כדי ליצור שילוב של אפליקציית Okta המשתמשת בפרוטוקול SAML, מבצעים את השלבים הבאים:

  1. נכנסים למסוף Admin של Okta.
  2. עוברים אל Applications > Applications.
  3. לוחצים על Create App Integration.
  4. בקטע Sign-in method, בוחרים את SAML 2.0 ולוחצים על Next.
  5. מזינים שם לאפליקציה ולוחצים על Next כדי להמשיך לאפשרויות של Configure SAML.

  6. בשדה Single Sign On URL, מזינים כתובת URL להפניה אוטומטית. זוהי כתובת ה-URL שהמשתמשים מופנים אליה אחרי שהם נכנסים. אם מגדירים את הגישה למסוף, משתמשים בפורמט הבא של כתובות URL. 

    https://auth.cloud.google/signin-callback/locations/global/workforcePools/WORKFORCE_POOL_ID/providers/WORKFORCE_PROVIDER_ID

  7. מזינים את Audience URI (SP Entity ID). הפורמט של המזהה הוא:

    https://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/providers/WORKFORCE_PROVIDER_ID

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

    • ‫WORKFORCE_POOL_ID: המזהה של מאגר הזהויות של כוח העבודה שיצרתם קודם במדריך הזה
    • ‫WORKFORCE_PROVIDER_ID: המזהה של ספק הזהויות של כוח העבודה שבחרתם, לדוגמה: okta-saml-provider

    מידע על הפורמט של המזהה מופיע בקטע פרמטרים של שאילתה במאמרי העזרה של ה-API.

  8. אופציונלי: אפשר להשתמש בהצהרות מאפיינים כדי לציין מאפיינים בהתאמה אישית שרוצים לשלוח בטענת הנכונות (assertion) של SAML. אחרי ההגדרה אפשר להשתמש במאפיינים האלו ב- Google Cloud כדי ליצור כללי מדיניות לניהול הרשאות גישה או במאפיין attribute_condition. לדוגמה, במדריך הזה ממפים את המחלקה באופן הבא:

    שם ערך
    department user.department

    אופציונלי: כדי להוסיף את הבקשה לקבוצות משתמשים שתשמש בהמשך המדריך, ראו איך מעבירים חברות בקבוצה של משתמש בטענת נכונות (assertion) של SAML.

  9. סיום יצירת שילוב אפליקציית Okta.

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

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

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

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

  1. כדי לקבל את מזהה הלקוח לשילוב עם אפליקציית ה-Okta, מבצעים את הפעולות הבאות:

    1. עוברים לשילוב אפליקציית ה-Okta.
    2. לוחצים על הכרטיסייה General.
    3. מעתיקים את התוכן של השדה Client ID.

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

    gcloud

    זרימת קוד

    ב-Okta, מבצעים את הפעולות הבאות:

    1. ב-Client authentication, בוחרים Client secret.

    2. בטבלה Client Secrets מוצאים את הסוד ולוחצים על Copy.

    ב- Google Cloud, כדי ליצור ספק OIDC שמשתמש בהרשאה באמצעות קוד לצורך כניסה לאינטרנט, מריצים את הפקודה הבאה:

    gcloud iam workforce-pools providers create-oidc WORKFORCE_PROVIDER_ID \
    --workforce-pool=WORKFORCE_POOL_ID \
    --display-name="DISPLAY_NAME" \
    --description="DESCRIPTION" \
    --issuer-uri="ISSUER_URI" \
    --client-id="OIDC_CLIENT_ID" \
        --client-secret-value="OIDC_CLIENT_SECRET" \
    --web-sso-response-type="code" \
    --web-sso-assertion-claims-behavior="merge-user-info-over-id-token-claims" \
    --web-sso-additional-scopes="WEB_SSO_ADDITIONAL_SCOPES" \
    --attribute-mapping="ATTRIBUTE_MAPPING" \
    --attribute-condition="ATTRIBUTE_CONDITION" \
    --jwk-json-path="JWK_JSON_PATH" \
    --detailed-audit-logging \
    --location=global

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

    • ‫WORKFORCE_PROVIDER_ID: מזהה ייחודי של ספק מאגר הזהויות של כוח העבודה. התוספת לשם המאפיין gcp- שמורה ואי אפשר להשתמש בה במזהה של מאגר זהויות של כוח עבודה או של ספק מאגר זהויות של כוח עבודה.
    • ‫WORKFORCE_POOL_ID: המזהה של מאגר הזהויות של כוח העבודה שאליו רוצים לחבר את ה-IdP.
    • ‫DISPLAY_NAME: שם תצוגה ידידותי למשתמש בשביל הספק (לא חובה); לדוגמה, idp-eu-employees.
    • ‫DESCRIPTION: תיאור של ספק כוח העבודה (לא חובה), לדוגמה, IdP for Partner Example Organization employees.
    • ‫ISSUER_URI: ה-URI של מנפיק OIDC, בפורמט URI תקין שמתחיל ב-https. לדוגמה: https://example.com/oidc. הערה: מטעמי אבטחה, ISSUER_URI צריך להשתמש בסכמת HTTPS.
    • ‫OIDC_CLIENT_ID: מזהה הלקוח ב-OIDC שרשום ב-IdP של OIDC. המזהה צריך להיות תואם להצהרת aud של ה-JWT שמונפקת על ידי ה-IdP.
    • OIDC_CLIENT_SECRET: סוד הלקוח ב-OIDC.
    • ‫WEB_SSO_ADDITIONAL_SCOPES: היקפי הרשאות אופציונליים לשליחה לספק הזהויות (IdP) של OIDC למסוף (איחוד) או לכניסה באמצעות הדפדפן ל-CLI של gcloud. לדוגמה, groups כדי לבקש את בקשת קבוצות המשתמשים מ-Okta אם עושים שימוש בשרת ההרשאות הארגוני של Okta.
    • ‫ATTRIBUTE_MAPPING: מיפוי מאפיינים. דוגמה למיפוי מאפיינים:
      ‫
      google.subject=assertion.oid
google.groups=assertion.groups,
attribute.costcenter=assertion.costcenter
       בדוגמה הזו, מאפייני ה-IdP‏ assertion.oid,‏ assertion.groups ו-assertion.costcenter בטענת הנכונות (assertion) של OIDC ממופים למאפיינים Google Cloud ‏ google.subject,‏ google.groups ו-attribute.costcenter בהתאמה.
    • ‫ATTRIBUTE_CONDITION: תנאי למאפיין; לדוגמה, assertion.subject.endsWith('@example.com') כשהערך של subject שמופה קודם מכיל כתובת אימייל שמסתיימת ב-@example.com.
    • ‫JWK_JSON_PATH: נתיב אופציונלי למפתחות JWK ב-OIDC שהועלו באופן מקומי. אם לא מוסיפים את הפרמטר הזה,המערכת של Google Cloud תשתמש בנתיב /.well-known/openid-configuration של ה-IdP כדי למצוא את מפתחות ה-JWK שמכילים את המפתחות הציבוריים. למידע נוסף על מפתחות JWK של OIDC שהועלו באופן מקומי, אפשר לעיין במאמר בנושא ניהול מפתחות JWK של OIDC.

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

      כדי להשבית את הרישום המפורט ביומן הביקורת של ספק מאגר זהויות של כוח עבודה, משמיטים את הדגל --detailed-audit-logging כשמריצים את הפקודה gcloud iam workforce-pools providers create. כדי להשבית את רישום הביקורת המפורט, אפשר גם לעדכן את הספק.

    בתשובה לפקודה, POOL_RESOURCE_NAME הוא שם המאגר. לדוגמה: locations/global/workforcePools/enterprise-example-organization-employees.

    זרם הענקת גישה משתמע

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

    gcloud iam workforce-pools providers create-oidc WORKFORCE_PROVIDER_ID \
    --workforce-pool=WORKFORCE_POOL_ID \
    --display-name="DISPLAY_NAME" \
    --description="DESCRIPTION" \
    --issuer-uri="ISSUER_URI" \
    --client-id="OIDC_CLIENT_ID" \
    --web-sso-response-type="id-token" \
    --web-sso-assertion-claims-behavior="only-id-token-claims" \
    --web-sso-additional-scopes="WEB_SSO_ADDITIONAL_SCOPES" \
    --attribute-mapping="ATTRIBUTE_MAPPING" \
    --attribute-condition="ATTRIBUTE_CONDITION" \
    --jwk-json-path="JWK_JSON_PATH" \
    --detailed-audit-logging \
    --location=global

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

    • ‫WORKFORCE_PROVIDER_ID: מזהה ייחודי של ספק מאגר הזהויות של כוח העבודה. התוספת לשם המאפיין gcp- שמורה ואי אפשר להשתמש בה במזהה של מאגר זהויות של כוח עבודה או של ספק מאגר זהויות של כוח עבודה.
    • ‫WORKFORCE_POOL_ID: המזהה של מאגר הזהויות של כוח העבודה שאליו רוצים לחבר את ה-IdP.
    • ‫DISPLAY_NAME: שם תצוגה ידידותי למשתמש בשביל הספק (לא חובה); לדוגמה, idp-eu-employees.
    • ‫DESCRIPTION: תיאור של ספק כוח העבודה (לא חובה), לדוגמה, IdP for Partner Example Organization employees.
    • ‫ISSUER_URI: ה-URI של מנפיק OIDC, בפורמט URI תקין שמתחיל ב-https. לדוגמה: https://example.com/oidc. הערה: מטעמי אבטחה, ISSUER_URI צריך להשתמש בסכמת HTTPS.
    • ‫OIDC_CLIENT_ID: מזהה הלקוח ב-OIDC שרשום ב-IdP של OIDC. המזהה צריך להיות תואם להצהרת aud של ה-JWT שמונפקת על ידי ה-IdP.
    • ‫WEB_SSO_ADDITIONAL_SCOPES: היקפי הרשאות אופציונליים לשליחה לספק הזהויות (IdP) של OIDC למסוף (איחוד) או לכניסה באמצעות הדפדפן ל-CLI של gcloud. לדוגמה, groups כדי לבקש את בקשת קבוצות המשתמשים מ-Okta אם עושים שימוש בשרת ההרשאות הארגוני של Okta.
    • ‫ATTRIBUTE_MAPPING: מיפוי מאפיינים. דוגמה למיפוי מאפיינים:
      ‫
      google.subject=assertion.oid
google.groups=assertion.groups,
attribute.costcenter=assertion.costcenter
       בדוגמה הזו, מאפייני ה-IdP‏ assertion.oid,‏ assertion.groups ו-assertion.costcenter בטענת הנכונות (assertion) של OIDC ממופים למאפיינים Google Cloud ‏ google.subject,‏ google.groups ו-attribute.costcenter בהתאמה.
    • ‫ATTRIBUTE_CONDITION: תנאי למאפיין; לדוגמה, assertion.subject.endsWith('@example.com') כשהערך של subject שמופה קודם מכיל כתובת אימייל שמסתיימת ב-@example.com.
    • ‫JWK_JSON_PATH: נתיב אופציונלי למפתחות JWK ב-OIDC שהועלו באופן מקומי. אם לא מוסיפים את הפרמטר הזה,המערכת של Google Cloud תשתמש בנתיב /.well-known/openid-configuration של ה-IdP כדי למצוא את מפתחות ה-JWK שמכילים את המפתחות הציבוריים. למידע נוסף על מפתחות JWK של OIDC שהועלו באופן מקומי, אפשר לעיין במאמר בנושא ניהול מפתחות JWK של OIDC.

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

      כדי להשבית את הרישום המפורט ביומן הביקורת של ספק מאגר זהויות של כוח עבודה, משמיטים את הדגל --detailed-audit-logging כשמריצים את הפקודה gcloud iam workforce-pools providers create. כדי להשבית את רישום הביקורת המפורט, אפשר גם לעדכן את הספק.

    בתשובה לפקודה, POOL_RESOURCE_NAME הוא שם המאגר. לדוגמה: locations/global/workforcePools/enterprise-example-organization-employees.

    המסוף

    זרימת קוד

    1. ב-Okta, מבצעים את הפעולות הבאות:

      1. ב-Client authentication, בוחרים Client secret.

      2. בטבלה Client Secrets מוצאים את הסוד ולוחצים על Copy.

    2. כדי ליצור ספק OIDC שמשתמש בהרשאה באמצעות קוד במסוף Google Cloud :

      1. במסוף Google Cloud , עוברים לדף Workforce Identity Pools:

        כניסה לדף Workforce Identity Pools

      2. בטבלה Workforce Identity Pools (מאגרי זהויות של כוח עבודה), בוחרים את המאגר שעבורו רוצים ליצור את הספק.

      3. בקטע ספקים, לוחצים על הוספת ספק.

      4. ברשימה Select a Provider vendor בוחרים את ספק ה-IdP.

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

      5. בקטע Select an authentication protocol, בוחרים באפשרות OpenID Connect (OIDC).

      6. בקטע Create a provider (יצירת ספק), מבצעים את הפעולות הבאות:

        1. בקטע שם, מזינים את שם הספק.
        2. בשדה תיאור, מזינים את התיאור של הספק.
        3. בקטע מנפיק (כתובת URL), מזינים את ה-URI של המנפיק. ה-URI של מנפיק OIDC צריך להיות בפורמט URI תקין ולהתחיל ב-https. לדוגמה: https://example.com/oidc.
        4. בקטע מזהה לקוח, מזינים את מזהה הלקוח ב-OIDC שרשום ב-IdP של OIDC. המזהה צריך להיות תואם להצהרת aud של ה-JWT שמונפקת על ידי ה-IdP.

        5. כדי ליצור ספק שמופעל, מוודאים שהאפשרות הפעלת הספק מופעלת.

        6. לוחצים על Continue.

      7. בקטע Share your provider information with IdP (שיתוף פרטי הספק עם IdP), מעתיקים את כתובת ה-URL. ב-IdP, מגדירים את כתובת ה-URL הזו כ-URI להפניה אוטומטית, כדי שה-IdP יידע לאן לשלוח את אסימון טענת הנכוֹנוּת (assertion) אחרי הכניסה לחשבון.

      8. לוחצים על Continue.

      9. בקטע Configure OIDC Web Sign-in (הגדרת כניסה לאינטרנט באמצעות OIDC), מבצעים את הפעולות הבאות:

        1. ברשימה סוג הזרימה, בוחרים באפשרות קוד.

        2. ברשימה Assertion claims behavior, בוחרים באחת מהאפשרויות הבאות:

          • פרטי משתמש ואסימון מזהה
          • אסימון מזהה בלבד

        3. בשדה Client secret (סוד הלקוח), מזינים את סוד הלקוח מספק ה-IdP.

        4. אופציונלי: אם בחרתם ב-Okta כספק הזהויות, מוסיפים היקפי הרשאות נוספים של OIDC בשדה Additional scopes beyond openid, profile, and email (היקפי הרשאות נוספים מעבר ל-openid, לפרופיל ולאימייל).

      10. לוחצים על Continue.

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

        1. חובה: בשדה OIDC 1, מזינים את הנושא מ-IdP – לדוגמה, assertion.sub.

        2. אופציונלי: כדי להוסיף מיפויים נוספים של מאפיינים:

          1. לוחצים על הוספת מיפוי.
          2. ב-Google n, כאשר n הוא מספר, מזינים אחד מהמקשים הנתמכים ב-Google Cloud.
          3. בשדה המתאים OIDC n, מזינים את השם של השדה הספציפי ל-IdP שרוצים למפות, בפורמט CEL.

        3. אם בחרתם ב-Microsoft Entra ID כספק הזהויות, אתם יכולים להגדיל את מספר הקבוצות.

          1. בוחרים באפשרות שימוש במאפיינים נוספים.
          2. בשדה Extra Attributes Issuer URI (מזהה URI של מנפיק מאפיינים נוספים), מזינים את כתובת ה-URL של המנפיק.
          3. בשדה מזהה לקוח של מאפיינים נוספים, מזינים את מזהה הלקוח.
          4. בשדה Extra Attributes Client Secret (סוד לקוח של מאפיינים נוספים), מזינים את סוד הלקוח.
          5. ברשימה Extra Attributes Type, בוחרים סוג מאפיין למאפיינים נוספים.
          6. בשדה Extra Attributes Filter, מזינים ביטוי סינון שמשמש לשליחת שאילתות ל-Microsoft Graph API לגבי קבוצות.

        4. כדי ליצור תנאי מאפיין:

          1. לוחצים על הוספת תנאי.
          2. בשדה Attribute Conditions, מזינים תנאי בפורמט CEL; לדוגמה, assertion.subject.endsWith('@example.com') כשהערך של subject שמופה קודם מכיל כתובת אימייל שמסתיימת ב-@example.com.

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

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

          כדי להשבית את הרישום המפורט ביומן הביקורת של ספק מאגר זהויות של כוח עבודה, משמיטים את הדגל --detailed-audit-logging כשמריצים את הפקודה gcloud iam workforce-pools providers create. כדי להשבית את רישום הביקורת המפורט, אפשר גם לעדכן את הספק.

      12. כדי ליצור את הספק, לוחצים על Submit (שליחה).

    זרם הענקת גישה משתמע

    1. במסוף Google Cloud Google Cloud :

      1. במסוף Google Cloud , עוברים לדף Workforce Identity Pools:

        כניסה לדף Workforce Identity Pools

      2. בטבלה Workforce Identity Pools (מאגרי זהויות של כוח עבודה), בוחרים את המאגר שעבורו רוצים ליצור את הספק.

      3. בקטע ספקים, לוחצים על הוספת ספק.

      4. ברשימה Select a Provider vendor בוחרים את ספק ה-IdP.

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

      5. בקטע Select an authentication protocol, בוחרים באפשרות OpenID Connect (OIDC).

      6. בקטע Create a provider (יצירת ספק), מבצעים את הפעולות הבאות:

        1. בקטע שם, מזינים את שם הספק.
        2. בשדה תיאור, מזינים את התיאור של הספק.
        3. בקטע מנפיק (כתובת URL), מזינים את ה-URI של המנפיק. ה-URI של מנפיק OIDC צריך להיות בפורמט URI תקין ולהתחיל ב-https. לדוגמה: https://example.com/oidc.
        4. בקטע מזהה לקוח, מזינים את מזהה הלקוח ב-OIDC שרשום ב-IdP של OIDC. המזהה צריך להיות תואם להצהרת aud של ה-JWT שמונפקת על ידי ה-IdP.
        5. כדי ליצור ספק שמופעל, מוודאים שהאפשרות הפעלת הספק מופעלת.
        6. לוחצים על Continue.

      7. בקטע Share your provider information with IdP (שיתוף פרטי הספק עם IdP), מעתיקים את כתובת ה-URL. ב-IdP, מגדירים את כתובת ה-URL הזו ככתובת ה-URI להפניה אוטומטית, שמציינת ל-IdP לאן לשלוח את אסימון הנכוֹנוּת אחרי הכניסה לחשבון.

      8. לוחצים על Continue.

      9. בקטע Configure OIDC Web Sign-in (הגדרת כניסה לאינטרנט באמצעות OIDC), מבצעים את הפעולות הבאות:

        1. ברשימה סוג התהליך, בוחרים באפשרות ID Token.

        2. ברשימה Assertion claims behavior (התנהגות של הצהרות על טענות), האפשרות ID token (טוקן מזהה) מסומנת.

        3. אופציונלי: אם בחרתם ב-Okta כספק הזהויות, מוסיפים היקפי הרשאות נוספים של OIDC בשדה Additional scopes beyond openid, profile, and email (היקפי הרשאות נוספים מעבר ל-openid, לפרופיל ולאימייל).

      10. לוחצים על Continue.

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

        1. חובה: ב-OIDC 1, מזינים את הנושא מ-IdP. לדוגמה, assertion.sub.

        2. אופציונלי: כדי להוסיף מיפויים נוספים של מאפיינים:

          1. לוחצים על הוספת מיפוי.
          2. ב-Google n, כאשר n הוא מספר, מזינים אחד מהמקשים הנתמכים ב-Google Cloud.
          3. בשדה המתאים OIDC n, מזינים את השם של השדה הספציפי ל-IdP שרוצים למפות, בפורמט CEL.

        3. אם בחרתם ב-Microsoft Entra ID כספק הזהויות, אתם יכולים להגדיל את מספר הקבוצות.

          1. בוחרים באפשרות שימוש במאפיינים נוספים.
          2. בשדה Extra Attributes Issuer URI (מזהה URI של מנפיק מאפיינים נוספים), מזינים את כתובת ה-URL של המנפיק.
          3. בשדה מזהה לקוח של מאפיינים נוספים, מזינים את מזהה הלקוח.
          4. בשדה Extra Attributes Client Secret (סוד לקוח של מאפיינים נוספים), מזינים את סוד הלקוח.
          5. ברשימה Extra Attributes Type, בוחרים סוג מאפיין למאפיינים נוספים.
          6. בשדה Extra Attributes Filter, מזינים ביטוי סינון שמשמש לשליחת שאילתות ל-Microsoft Graph API לגבי קבוצות.

        4. כדי ליצור תנאי מאפיין:

          1. לוחצים על הוספת תנאי.
          2. בשדה Attribute Conditions, מזינים תנאי בפורמט CEL; לדוגמה, assertion.subject.endsWith('@example.com') כשהערך של subject שמופה קודם מכיל כתובת אימייל שמסתיימת ב-@example.com.

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

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

          כדי להשבית את הרישום המפורט ביומן הביקורת של ספק מאגר זהויות של כוח עבודה, משמיטים את הדגל --detailed-audit-logging כשמריצים את הפקודה gcloud iam workforce-pools providers create. כדי להשבית את רישום הביקורת המפורט, אפשר גם לעדכן את הספק.

      12. כדי ליצור את הספק, לוחצים על Submit (שליחה).

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

  1. ב-IdP שתומך ב-SAML, רושמים אפליקציה חדשה לאיחוד שירותי אימות הזהות של כוח העבודה ב- Google Cloud.

  2. מגדירים את הקהל לטענת הנכוֹנוּת (assertion) של SAML. בדרך כלל משתמשים בשדה SP Entity ID בהגדרות שלכם ב-IdP. צריך להגדיר אותו כך שיכיל את כתובת ה-URL הבאה:

    https://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/providers/WORKFORCE_PROVIDER_ID

  3. מגדירים את כתובת ה-URL להפניה אוטומטית, שנקראת גם כתובת ה-URL של Assertion Consumer Service‏ (ACS). כדי להגדיר את כתובת ה-URL להפניה אוטומטית, מאתרים את השדה של כתובת ה-URL להפניה אוטומטית ב-IdP של SAML, ומבצעים אחת מהפעולות הבאות:

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

      https://auth.cloud.google/signin-callback/locations/global/workforcePools/WORKFORCE_POOL_ID/providers/WORKFORCE_PROVIDER_ID

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

      • ‫WORKFORCE_POOL_ID: המזהה של מאגר הזהויות של כוח העבודה

      • ‫WORKFORCE_PROVIDER_ID: המזהה של ספק הזהויות של כוח העבודה שתיצרו בהמשך המסמך הזה.

    • כדי להגדיר כניסה באמצעות תוכנה דרך ה-IdP, מזינים את כתובת ה-URL הבאה:

      localhost

    פרטים נוספים זמינים במאמר הגדרת הגישה של משתמשים למסוף.

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

    • מזהה ישות ב-SAML ל-IdP שלכם.
    • כתובת ה-URL לכניסה יחידה (SSO) ל-IdP שלכם.
    • לפחות מפתח ציבורי אחד לחתימה אפשר לקרוא פרטים נוספים על חתימת מפתחות בקטע דרישות עיקריות בהמשך המדריך הזה.

gcloud

כדי ליצור ספק של מאגר זהויות של כוח עבודה בשביל שילוב אפליקציית Okta באמצעות פרוטוקול SAML, מבצעים את הפעולות הבאות:

  1. כדי לשמור מטא-נתונים של SAML בשביל אפליקציית Okta, מבצעים את הפעולות הבאות:

    1. נכנסים לאפליקציית Okta.
    2. לוחצים על הכרטיסייה Sign On.
    3. בקטע SAML Signing Certificates, לוחצים על Actions > View IdP metadata בשביל האישור הפעיל.
    4. בדף החדש שנפתח, מעתיקים את המטא-נתונים של ה-XML.
    5. שומרים את המטא-נתונים כקובץ XML מקומי.

  2. כדי ליצור ספק כוח עבודה לאפליקציית Okta, מריצים את הפקודה הבאה:

    gcloud iam workforce-pools providers create-saml WORKFORCE_PROVIDER_ID \
    --workforce-pool="WORKFORCE_POOL_ID" \
    --attribute-mapping="ATTRIBUTE_MAPPING" \
    --attribute-condition="ATTRIBUTE_CONDITION" \
    --idp-metadata-path="XML_METADATA_PATH" \
    --detailed-audit-logging \
    --location="global"

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

    • ‫WORKFORCE_PROVIDER_ID: המזהה של ספק כוח העבודה שיצרתם קודם במדריך הזה.
    • ‫WORKFORCE_POOL_ID: המזהה של מאגר הזהויות של כוח העבודה שיצרתם קודם במדריך הזה.

    • ‫ATTRIBUTE_MAPPING: מיפוי מאפיינים – לדוגמה:

      google.subject=assertion.oid
attribute.costcenter=assertion.attributes.costcenter[0]
       בדוגמה הזו, מאפייני ה-IdP‏ assertion.oid ו-assertion.attributes.costcenter[0] ממופים למאפיינים Google Cloud ‏ google.subject ו-attribute.costcenter, בהתאמה.

    • ‫ATTRIBUTE_CONDITION: תנאי למאפיין (לא חובה). לדוגמה, כדי להגביל את המאפיין ipaddr לטווח מסוים של כתובות IP, אפשר ליצור את התנאי assertion.attributes.ipaddr.startsWith('98.11.12.'). התנאי הזה מבטיח שרק משתמשים עם כתובת IP שמתחילה ב-98.11.12. יוכלו להיכנס באמצעות ספק הזהויות הזה לכוח העבודה.

    • ‫XML_METADATA_PATH: הנתיב לקובץ המטא-נתונים בפורמט XML של אפליקציית Okta שיצרתם קודם במדריך הזה.

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

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

      כדי להשבית את הרישום המפורט ביומן הביקורת של ספק מאגר זהויות של כוח עבודה, משמיטים את הדגל --detailed-audit-logging כשמריצים את הפקודה gcloud iam workforce-pools providers create. כדי להשבית את רישום הביקורת המפורט, אפשר גם לעדכן את הספק.

    אופציונלי: אישור טענות נכונות (assertions) של SAML מוצפן מ-IdP

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

    • באיחוד שירותי אימות הזהות של כוח העבודה מבצעים את הפעולות הבאות:
      • יוצרים זוג מפתחות אסימטריים בשביל הספק של מאגר הזהויות של כוח העבודה.
      • מורידים קובץ אישור שמכיל את המפתח הציבורי.
      • מגדירים את ספק הזהויות ב-SAML כך שישתמש במפתח הציבורי להצפנה של טענות הנכוֹנוּת שהוא מנפיק ב-SAML.
    • מבצעים את הפעולות הבאות בספק הזהויות:
      • מפעילים את ההצפנה של טענות הנכוֹנוּת, שנקראת גם הצפנה באמצעות אסימון.
      • מעלים את המפתח הציבורי שיצרתם באיחוד שירותי אימות הזהות של כוח העבודה.
      • מוודאים שה-IdP מייצר טענות נכונות (assertions) מוצפנות ב-SAML.
    שימו לב שגם כשמוגדרים מפתחות הצפנה של הספק ב-SAML, איחוד שירותי אימות הזהות של כוח העבודה עדיין יכול לעבד טענות נכוֹנוּת שכתובות בטקסט ללא הצפנה.

    יצירת מפתחות הצפנה לטענות נכוֹנוּת ב-SAML של איחוד שירותי אימות הזהות של כוח העבודה

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

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

    gcloud iam workforce-pools providers keys create KEY_ID \
    --workforce-pool WORKFORCE_POOL_ID \
    --provider WORKFORCE_PROVIDER_ID \
    --location global \
    --use encryption \
    --spec KEY_SPECIFICATION

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

    • ‫KEY_ID: שם המפתח שבחרתם
    • ‫WORKFORCE_POOL_ID: מזהה המאגר
    • ‫WORKFORCE_PROVIDER_ID: המזהה של ספק מאגר הזהויות של כוח העבודה
    • KEY_SPECIFICATION: מפרט המפתחות, שיכול להיות אחד מאלה: rsa-2048, ‏rsa-3072 או rsa-4096.

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

    gcloud iam workforce-pools providers keys describe KEY_ID \
    --workforce-pool WORKFORCE_POOL_ID \
    --provider WORKFORCE_PROVIDER_ID \
    --location global \
    --format "value(keyData.key)" \
    > CERTIFICATE_PATH

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

    • ‫KEY_ID: שם המפתח
    • ‫WORKFORCE_POOL_ID: מזהה המאגר
    • ‫WORKFORCE_PROVIDER_ID: המזהה של ספק מאגר הזהויות של כוח העבודה
    • CERTIFICATE_PATH: הנתיב שבו האישור ייכתב. לדוגמה: saml-certificate.cer או saml-certificate.pem

    הגדרת ה-IdP שתואם ל-SAML 2.0 כדי שינפיק טענות נכונות (assertions) מוצפנות של SAML

    כדי להגדיר את Okta להצפנת טענות נכונות (assertions) של SAML, מבצעים את הפעולות הבאות:

    • עוברים אל לוח הבקרה של Okta ונכנסים לחשבון.
    • עוברים אל Applications>Applications.
    • לוחצים על האפליקציה.
    • בכרטיסייה General, בקטע SAML settings לוחצים על Edit.
    • לוחצים על Next כדי לצפות ב-SAML Settings.
    • לוחצים על Show advanced settings.
    • ב-SAML Settings, מבצעים את הפעולות הבאות:
      • באחת מתוך Response (מועדף) או Assertion Signature, בוחרים Signed.
      • ב-Signature Algorithm וב-Digest Algorithm, בוחרים אפשרות כלשהי.
      • מגדירים את הערכים הבאים:
        • ‫Assertion Encryption: מוצפן.
        • ‫Encryption Algorithm: אלגוריתם כלשהו.
        • ‫Encryption Certificate: מעלים את קובץ האישור שיצרתם קודם במדריך הזה.
    • כדי לשמור את ההגדרות האישיות, לוחצים על Next ואז על Finish

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

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

    כדי למחוק את מפתחות ההצפנה ב-SAML, מריצים את הפקודה הבאה: 
      gcloud iam workforce-pools providers keys delete KEY_ID \
      --workforce-pool WORKFORCE_POOL_ID \
      --provider WORKFORCE_PROVIDER_ID \
      --location global

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

    • ‫KEY_ID: שם המפתח
    • ‫WORKFORCE_POOL_ID: מזהה המאגר
    • ‫WORKFORCE_PROVIDER_ID: המזהה של ספק מאגר הזהויות של כוח העבודה

    באילו אלגוריתמים אפשר להשתמש להצפנה ב-SAML

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

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

המסוף

כדי להגדיר ספק שתומך ב-SAML באמצעות מסוף Google Cloud :

  1. במסוף Google Cloud , עוברים לדף Workforce Identity Pools:

    כניסה לדף Workforce Identity Pools

  2. בטבלה Workforce Identity Pools (מאגרי זהויות של כוח עבודה), בוחרים את המאגר שרוצים ליצור לו את הספק.

  3. בקטע ספקים, לוחצים על הוספת ספק.

  4. ברשימה Select a Provider vendor בוחרים את ספק ה-IdP.

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

  5. בקטע Select an authentication protocol (בחירת פרוטוקול אימות), בוחרים באפשרות SAML.

  6. בקטע Create a provider (יצירת ספק), מבצעים את הפעולות הבאות:

    1. בשדה שם, מזינים שם לספק.

    2. אופציונלי: בשדה Description, מזינים תיאור של הספק.

    3. בקטע IDP metadata file (XML) (קובץ מטא-נתונים של ספק הזהויות (XML)), בוחרים את קובץ ה-XML של המטא-נתונים שיצרתם קודם במדריך הזה.

    4. כדי ליצור ספק שמופעל, מוודאים שהאפשרות הפעלת הספק מופעלת.

    5. לוחצים על Continue.

  7. בקטע Share your provider information, מעתיקים את כתובות ה-URL. ב-IdP, מגדירים את כתובת ה-URL הראשונה כמזהה ישות ב-SAML, שמזהה את האפליקציה שלכם ב-IdP. מגדירים את כתובת ה-URL השנייה כמזהה ה-URI להפניה אוטומטית, שמציין ל-IdP לאן לשלוח את אסימון האישור אחרי הכניסה.

  8. לוחצים על Continue.

  9. בקטע Configure provider (הגדרת ספק), מבצעים את הפעולות הבאות:

    1. בקטע מיפוי מאפיינים, מזינים ביטוי CEL עבור google.subject.

    2. אופציונלי: כדי להזין מיפויים אחרים, לוחצים על הוספת מיפוי ומזינים מיפויים אחרים – לדוגמה:

      google.subject=assertion.oid
attribute.costcenter=assertion.attributes.costcenter[0]
       בדוגמה הזו, מאפייני ה-IdP‏ assertion.oid ו-assertion.attributes.costcenter[0] ממופים למאפיינים Google Cloud ‏ google.subject ו-attribute.costcenter, בהתאמה.

    3. אם בחרתם ב-Microsoft Entra ID כספק הזהויות שלכם, אתם יכולים להגדיל את מספר הקבוצות על ידי ביצוע הפעולות הבאות:

      1. בוחרים באפשרות שימוש במאפיינים נוספים.
      2. בשדה Extra Attributes Issuer URI (מזהה URI של מנפיק מאפיינים נוספים), מזינים את כתובת ה-URL של המנפיק.
      3. בשדה מזהה לקוח של מאפיינים נוספים, מזינים את מזהה הלקוח.
      4. בשדה Extra Attributes Client Secret (סוד לקוח של מאפיינים נוספים), מזינים את סוד הלקוח.
      5. ברשימה Extra Attributes Type, בוחרים סוג מאפיין למאפיינים נוספים.
      6. בשדה Extra Attributes Filter, מזינים ביטוי סינון שמשמש לשליחת שאילתות ל-Microsoft Graph API לגבי קבוצות.

    4. אופציונלי: כדי להוסיף תנאי של מאפיין, לוחצים על הוספת תנאי ומזינים ביטוי CEL שמייצג תנאי של מאפיין. לדוגמה, כדי להגביל את המאפיין ipaddr לטווח מסוים של כתובות IP, אפשר ליצור את התנאי assertion.attributes.ipaddr.startsWith('98.11.12.'). התנאי הזה מבטיח שרק משתמשים עם כתובת IP שמתחילה ב-98.11.12. יוכלו להיכנס באמצעות ספק הזהויות הזה לכוח העבודה.

    5. לוחצים על Continue.

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

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

      כדי להשבית את הרישום המפורט ביומן הביקורת של ספק מאגר זהויות של כוח עבודה, משמיטים את הדגל --detailed-audit-logging כשמריצים את הפקודה gcloud iam workforce-pools providers create. כדי להשבית את רישום הביקורת המפורט, אפשר גם לעדכן את הספק.

  10. כדי ליצור את הספק, לוחצים על Submit (שליחה).

אימות ההגדרה של הספק

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

בדף Validate your provider attributes במסוף Google Cloud יש כלי לצפייה במאפיינים שמאפשר לבדוק את ההגדרה באופן אינטראקטיבי ולנפות באגים בביטויים של Common Expression Language‏ (CEL). בעזרת הכלי לבדיקת מאפיינים אפשר:

  • צפייה במאפיינים הגולמיים שנשלחים בהצהרת ה-IdP.
  • מוודאים שמיפויי המאפיינים והתנאים משנים את המאפיינים האלה בצורה נכונה.
  • ניפוי באגים של ביטויי CEL מורכבים בזמן אמת.

כדי לוודא שהגדרתם את הספק בצורה נכונה:

  1. כדי להפעיל את תהליך הכניסה מבוסס-הדפדפן לאיחוד שירותי אימות הזהות של כוח עבודה, מוסיפים את https://auth.cloud.google/signin-callback/locations/global/workforcePools/POOL_ID/providers/PROVIDER_ID לרשימת ה-URI להפניה אוטומטית המותרים ב-IdP.

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

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

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

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

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

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

עריכת הגדרת הספק

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

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

ניהול הגישה למשאבים Google Cloud

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

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

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

לזהויות בודדות

כדי להקצות את התפקיד Storage Admin (roles/storage.admin) לזהות יחידה של הפרויקט TEST_PROJECT_ID, מריצים את הפקודה הבאה:

gcloud projects add-iam-policy-binding TEST_PROJECT_ID \
    --role="roles/storage.admin" \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

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

  • ‫TEST_PROJECT_ID: המזהה של הפרויקט
  • ‫WORKFORCE_POOL_ID: המזהה של מאגר הזהויות של כוח העבודה
  • ‫SUBJECT_VALUE: זהות המשתמש

שימוש במאפיין של מחלקה ממופה

כדי להקצות את התפקיד Storage Admin (roles/storage.admin) לכל הזהויות במחלקה ספציפית בפרויקט, TEST_PROJECT_ID, מריצים את הפקודה הבאה:

gcloud projects add-iam-policy-binding TEST_PROJECT_ID \
    --role="roles/storage.admin" \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/attribute.department/DEPARTMENT_VALUE"

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

  • ‫TEST_PROJECT_ID: המזהה של הפרויקט
  • ‫WORKFORCE_POOL_ID: המזהה של מאגר הזהויות של כוח העבודה
  • ‫DEPARTMENT_VALUE: הערך הממופה של attribute.department

שימוש בקבוצות ממופות

כדי להקצות את התפקיד Storage Admin (roles/storage.admin) לכל הזהויות בקבוצה ספציפית בפרויקט TEST_PROJECT_ID, מריצים את הפקודה הבאה:

gcloud projects add-iam-policy-binding TEST_PROJECT_ID \
    --role="roles/storage.admin" \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

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

  • ‫TEST_PROJECT_ID: המזהה של הפרויקט
  • ‫WORKFORCE_POOL_ID: המזהה של מאגר הזהויות של כוח העבודה
  • ‫GROUP_ID: קבוצה בהצהרה הממופה google.groups.

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

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

כניסה

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

כניסה באמצעות הדפדפן ל-CLI של gcloud

כדי להיכנס ל-CLI של gcloud באמצעות הדפדפן, מבצעים את הפעולות הבאות:

יוצרים קובץ תצורה

כדי ליצור את קובץ התצורה לכניסה, מריצים את הפקודה הבאה. אפשר גם להפעיל את הקובץ כברירת המחדל בשביל ה-CLI של gcloud על ידי הוספת הדגל --activate. אחרי זה אפשר להריץ את הפקודה gcloud auth login בלי לציין את הנתיב של קובץ התצורה בכל פעם. 

gcloud iam workforce-pools create-login-config \
    locations/global/workforcePools/WORKFORCE_POOL_ID/providers/PROVIDER_ID \
    --output-file=LOGIN_CONFIG_FILE_PATH

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

  • ‫WORKFORCE_POOL_ID: מזהה מאגר כוח העבודה
  • ‫PROVIDER_ID: מזהה הספק
  • ‫LOGIN_CONFIG_FILE_PATH: הנתיב לקובץ התצורה שמציינים. לדוגמה: login.json

הקובץ מכיל את נקודות הקצה (endpoints) שבהן ה-CLI של gcloud משתמש כדי להפעיל את תהליך האימות בדפדפן ולהגדיר את הקהל לספק הזהויות שהוגדר במאגר הזהויות של כוח העבודה. הקובץ לא מכיל מידע סודי.

הפלט אמור להיראות כך:

{
  "type": "external_account_authorized_user_login_config",
  "audience": "//iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/providers/WORKFORCE_PROVIDER_ID",
  "auth_url": "https://auth.cloud.google/authorize",
  "token_url": "https://sts.googleapis.com/v1/oauthtoken",
  "token_info_url": "https://sts.googleapis.com/v1/introspect"
}

כדי למנוע מ-gcloud auth login להשתמש בקובץ התצורה הזה באופן אוטומטי, אפשר לבטל את ההגדרה שלו באמצעות הפקודה gcloud config unset auth/login_config_file.

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

כדי להיכנס באמצעות אימות בדפדפן, אפשר להשתמש באחת מהשיטות הבאות:

  • אם השתמשתם בדגל --activate כשיצרתם את קובץ התצורה, או אם הפעלתם את קובץ התצורה באמצעות gcloud config set auth/login_config_file, ה-CLI של gcloud ישתמש בקובץ התצורה שלכם באופן אוטומטי: 

    gcloud auth login

  • כדי להיכנס באמצעות ציון המיקום של קובץ התצורה, מריצים את הפקודה הבאה: 

    gcloud auth login --login-config=LOGIN_CONFIG_FILE_PATH
  • כדי להשתמש במשתנה סביבה לציון המיקום של קובץ התצורה, מגדירים את CLOUDSDK_AUTH_LOGIN_CONFIG_FILE כנתיב של קובץ תצורה.

השבתת הכניסה בדפדפן

כדי להפסיק להשתמש בקובץ התצורה שמשמש לכניסה:

  • אם השתמשתם בדגל --activate כשיצרתם את קובץ התצורה, או אם הפעלתם את קובץ התצורה באמצעות gcloud config set auth/login_config_file, צריך להשתמש בפקודה הבאה כדי לבטל אותו: 

    gcloud config unset auth/login_config_file
  • מוחקים את משתנה הסביבה CLOUDSDK_AUTH_LOGIN_CONFIG_FILE, אם הוא מוגדר.

כניסה באמצעות דפדפן ללא GUI ל-CLI של gcloud

כדי להיכנס ל-CLI של gcloud באמצעות דפדפן ללא GUI, מבצעים את הפעולות הבאות:

OIDC

  1. נכנסים כמשתמש לאפליקציית ה-Okta ומקבלים את אסימון ה-OIDC מ-Okta.

  2. שומרים את אסימון ה-OIDC שמוחזר על ידי Okta במיקום מאובטח במכונה המקומית.

  3. כדי ליצור קובץ תצורה כמו בדוגמה שבהמשך השלב הזה, מריצים את הפקודה הבאה:

    gcloud iam workforce-pools create-cred-config \
    locations/global/workforcePools/WORKFORCE_POOL_ID/providers/WORKFORCE_PROVIDER_ID \
    --subject-token-type="urn:ietf:params:oauth:token-type:id_token" \
    --credential-source-file="PATH_TO_OIDC_ID_TOKEN" \
    --workforce-pool-user-project="WORKFORCE_POOL_USER_PROJECT" \
    --output-file="config.json"

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

  • WORKFORCE_POOL_ID: מאגר הזהויות של כוח עבודה
  • ‫WORKFORCE_PROVIDER_ID: מזהה הספק
  • ‫PATH_TO_OIDC_TOKEN: הנתיב לקובץ פרטי הכניסה של ה-IdP ב-OIDC
  • ‫WORKFORCE_POOL_USER_PROJECT: מספר הפרויקט המשויך לפרויקט המשתמש של מאגרי כוח העבודה

לחשבון משתמש הזה צריכה להיות ההרשאה (serviceusage.services.use) בפרויקט הזה.

כשמריצים את הפקודה, נוצר קובץ תצורה בשביל IdP של OIDC שמפורמט באופן הבא:

{
  "type": "external_account",
  "audience": "//iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/providers/WORKFORCE_PROVIDER_ID",
  "subject_token_type": "urn:ietf:params:oauth:token-type:id_token",
  "token_url": "https://sts.googleapis.com/v1/token",
  "workforce_pool_user_project": "WORKFORCE_POOL_USER_PROJECT",
  "credential_source": {
    "file": "PATH_TO_OIDC_CREDENTIALS_FILE"
  }
}

SAML

  1. נכנסים כמשתמש לאפליקציית ה-Okta ומקבלים את התשובה של SAML מ-Okta.

  2. שומרים את התשובה של SAML שמוחזרת על ידי Okta במיקום מאובטח במכונה המקומית, ואז מאחסנים את הנתיב באופן הבא:

    SAML_ASSERTION_PATH=SAML_ASSERTION_PATH

  3. כדי ליצור קובץ תצורה, מריצים את הפקודה הבאה:

    gcloud iam workforce-pools create-cred-config \
    locations/global/workforcePools/WORKFORCE_POOL_ID/providers/WORKFORCE_PROVIDER_ID \
    --subject-token-type="urn:ietf:params:oauth:token-type:saml2" \
    --credential-source-file="SAML_ASSERTION_PATH"  \
    --workforce-pool-user-project="PROJECT_ID"  \
    --output-file="config.json"

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

    • ‫WORKFORCE_PROVIDER_ID: מזהה כוח העבודה שיצרתם קודם במדריך הזה.
    • ‫WORKFORCE_POOL_ID: המזהה של מאגר הזהויות של כוח העבודה שיצרתם קודם במדריך.
    • ‫SAML_ASSERTION_PATH: הנתיב לקובץ של טענת הנכונות ב-SAML.
    • ‫PROJECT_ID: מזהה הפרויקט

    קובץ התצורה שנוצר נראה כך:

    {
  "type": "external_account",
  "audience": "//iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/providers/WORKFORCE_PROVIDER_ID",
  "subject_token_type": "urn:ietf:params:oauth:token-type:saml2",
  "token_url": "https://sts.googleapis.com/v1/token",
  "credential_source": {
    "file": "SAML_ASSERTION_PATH"
  },
  "workforce_pool_user_project": "PROJECT_ID"
}

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

gcloud auth login --cred-file="config.json"

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

הפלט אמור להיראות כך:

Authenticated with external account user credentials for:
[principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/USER_ID].

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

gcloud auth list

כניסה לחשבון במסוף (איחוד)

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

  1. עוברים לדף הכניסה של המסוף (איחוד).

    כניסה למסוף (איחוד)

  2. מזינים את שם הספק בפורמט הבא: 
    locations/global/workforcePools/WORKFORCE_POOL_ID/providers/WORKFORCE_PROVIDER_ID

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

    אם מתחילים תהליך כניסה ביוזמת IdP, משתמשים בכתובת ה-URL הבאה ב-SAML Settings של הפרמטר בתוך פרמטר Default RelayState:https://console.cloud.google/

בדיקת גישה

עכשיו יש לכם גישה לשירותי Google Cloud שתומכים באיחוד שירותי אימות הזהות של כוח העבודה, ושאליהם ניתנה לכם גישה. מוקדם יותר במדריך הזה הקציתם את התפקיד Storage Admin (roles/storage.admin) לכל הזהויות במחלקה ספציפית בפרויקט TEST_PROJECT_ID. עכשיו תוכלו לבדוק אם יש לכם גישה על ידי הצגת הרשימה של הקטגוריות של Cloud Storage.

‫CLI של gcloud

כדי לראות את הקטגוריות והאובייקטים של Cloud Storage בפרויקט שיש אליו גישה, מריצים את הפקודה הבאה:

gcloud storage ls --project="TEST_PROJECT_ID"

לחשבון המשתמש צריכה להיות ההרשאה serviceusage.services.use בפרויקט שצוין.

מסוף (איחוד)

כדי להציג רשימת קטגוריות של Cloud Storage באמצעות המסוף (איחוד), מבצעים את הפעולות הבאות:

  • מעבר לדף Cloud Storage.
  • מוודאים שאפשר לראות את רשימת הקטגוריות הקיימות של TEST_PROJECT_ID.

מחק משתמשים

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

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

המאמרים הבאים