הגדרות אדמין – אימות OpenID Connect

חברות משתמשות בספקי OpenID Connect (OP) שונים כדי לתאם עם OpenID Connect (לדוגמה, Okta או OneLogin). יכול להיות שהמונחים שבהם נעשה שימוש בהוראות ההגדרה הבאות ובממשק המשתמש של Looker לא יהיו זהים למונחים שבהם נעשה שימוש ב-OP שלכם.

בדף OpenID Connect שבקטע אימות בתפריט Admin, אפשר להגדיר את Looker כך שיאמת משתמשים באמצעות פרוטוקול OpenID Connect. בדף הזה מוסבר על התהליך ומופיעות הוראות לקישור קבוצות OpenID Connect לתפקידים ולהרשאות ב-Looker.

דרישות

הדף OpenID Connect מוצג ב-Looker בקטע אימות בתפריט אדמין רק אם מתקיימים התנאים הבאים:

  • יש לכם תפקיד אדמין.
  • המופע של Looker מופעל לשימוש ב-OpenID Connect. כדי להפעיל את OpenID Connect, צריך לפנות למנהל החשבון. הדף הזה מופעל כברירת מחדל במופעים של Looker (Google Cloud core).

אם התנאים האלה מתקיימים ואתם לא רואים את הדף OpenID Connect, פתחו בקשת תמיכה כדי להפעיל את OpenID Connect במופע שלכם.

שיקולים בתכנון

  • כדאי להשתמש באפשרות כניסה חלופית למשתמשים ספציפיים כדי לאפשר לאדמינים של Looker לגשת ל-Looker בלי OpenID Connect.
  • אל תשביתו את האימות באמצעות OpenID Connect בזמן שאתם מחוברים ל-Looker באמצעות OpenID Connect, אלא אם הגדרתם כניסה לחשבון חלופי. אחרת, יכול להיות שלא תוכלו להיכנס יותר לאפליקציה.
  • ‫Looker יכול להעביר חשבונות קיימים ל-OpenID Connect באמצעות כתובות אימייל שמגיעות מהגדרות אימייל וסיסמה נוכחיות, מ-LDAP, מ-SAML או מאימות Google. תוכלו להגדיר את זה בתהליך ההגדרה.
  • ‫Looker תומך באימות OpenID Connect רק באמצעות ההרשאה באמצעות קוד של OpenID Connect. אין תמיכה בתהליכי קוד אחרים.
  • מפרט OpenID Connect כולל מנגנון אופציונלי של Discovery. ‫Looker לא תומך במנגנון הזה, ולכן צריך לספק כתובות URL מפורשות בקטע OpenID Connect Auth Settings (הגדרות אימות OpenID Connect), כמו שמתואר במאמר בנושא הגדרת אימות OpenID Connect.

הגדרת OpenID Connect

כדי להגדיר את החיבור בין Looker לבין OpenID Connect, מבצעים את המשימות הבאות:

  1. מעבירים את כתובת ה-URL של Looker לספק OpenID Connect (OP).
  2. קבלת המידע הנדרש מה-OP
  3. הגדרת אימות OpenID Connect במופע Looker

הגדרת Looker בפלטפורמה שלכם

ספק OpenID Connect ‏ (OP) יצטרך את כתובת ה-URL של המכונה של Looker. יכול להיות שספק הזהות יקרא לזה URI של הפניה או URI של הפניה להתחברות, בין שמות אחרים. באתר של ספק ה-OP, מספקים לספק את כתובת ה-URL שדרכה בדרך כלל ניגשים למכונה של Looker בדפדפן, ואחריה את התו /openidconnect. לדוגמה, https://instance_name.looker.com/openidconnect.

קבלת מידע מה-OP

כדי להגדיר את Looker לאימות OpenID Connect, צריך את הפרטים הבאים מספק הזהויות:

  • מזהה לקוח וסוד לקוח. בדרך כלל, ספק ה-OP מספק את ה-URI האלה באתר שלו כשמגדירים את ה-URI להפניה אוטומטית.
  • במהלך תהליך האימות של OpenID Connect,‏ Looker מתחבר לשלוש נקודות קצה שונות: נקודת קצה של אימות, נקודת קצה של אסימון מזהה ונקודת קצה של פרטי משתמש. תצטרכו את כתובות ה-URL שספק ה-OP משתמש בהן לכל אחת מנקודות הקצה האלה.
  • כל ספק זהויות יספק מידע על המשתמשים בקבוצות שנקראות היקפי הרשאה. צריך לדעת את השמות של היקפי ההרשאות שספק ה-OP משתמש בהם. ‫OpenID Connect דורש את היקף openid, אבל סביר להניח שספק ה-OP שלכם יכלול היקפים אחרים, כמו email,‏ profile ו-groups.
  • ב-OpenID Connect, מאפיינים שמאחסנים נתוני משתמשים נקראים טענות. אתם צריכים לדעת אילו טענות מועברות מ-OP ל-Looker כדי לספק את פרטי המשתמש שאתם רוצים במופע Looker שלכם. ‫Looker דורש טענות שמכילות מידע על כתובת אימייל ושם, אבל אם יש לכם מאפייני משתמש אחרים, כמו אזור זמן או מחלקה, מערכת Looker תצטרך גם לזהות אילו טענות מכילות את המידע הזה. אפשר לכלול הצהרות בתגובה מנקודת הקצה של פרטי המשתמש או מנקודת הקצה של אסימון המזהה. ‫Looker יכול למפות הצהרות שמוחזרות על ידי נקודת הקצה למאפייני משתמש ב-Looker.

הרבה ספקי OpenID מספקים מידע על הגדרת OpenID Connect בצורה של מסמך Discovery, שמאפשר לכם לאסוף חלק מהמידע שתצטרכו להגדיר את Looker ל-OpenID Connect, או את כולו. אם אין לכם גישה למסמך Discovery, אתם צריכים לקבל את המידע הנדרש מספק ה-OP או מצוות האימות הפנימי שלכם.

הקטע הבא הוא דוגמה למסמך Discovery:

{
  "issuer": "https://accounts.google.com",
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "token_endpoint": "https://www.googleapis.com/oauth2/v4/token",
  "userinfo_endpoint": "https://www.googleapis.com/oauth2/v3/userinfo",
  "revocation_endpoint": "https://accounts.google.com/o/oauth2/revoke",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
  "response_types_supported": [
    "code",
    "token",
    "id_token",
    "code token"
    "code id_token",
    "token id_token",
    "code token id_token",
    "none"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "scopes_supported": [
    "openid",
    "email",
    "profile"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_post",
    "client_secret_basic"
  ],
  "claims_supported": [
    "aud",
    "email",
    "email_verified",
    "exp",
    "family_name",
    "given_name",
    "iat",
    "iss",
    "locale",
    "name",
    "picture",
    "sub"
  ],

הגדרת הגדרות אימות OpenID Connect

כדי להגדיר אימות OpenID Connect במופע Looker, בוחרים באפשרות OpenID Connect בקטע Authentication בלוח Admin. בדף OpenID Connect Authentication, בוחרים באפשרות Configure OpenID Connect.

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

מזהה: מזהה הלקוח שייחודי למופע Looker שלכם. הספק יספק את השם הזה.

סוד: מפתח סוד הלקוח הייחודי למופע Looker שלכם. הספק יספק את השם הזה.

מנפיק: כתובת ה-URL המאובטחת שמזהה את ספק ה-OP שלכם.

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

כתובת URL להרשאה: כתובת ה-URL של ספק הזהויות שבו מתחיל רצף האימות. נקרא לעיתים קרובות authorization_endpoint במסמך Discovery.

כתובת ה-URL של הטוקן: כתובת ה-URL שבה Looker מאחזר טוקן OAuth אחרי שניתנה ל-Looker הרשאה. נקרא לעיתים קרובות token_endpoint במסמך Discovery.

כתובת ה-URL של פרטי המשתמש: כתובת ה-URL שבה Looker יאחזר פרטים על המשתמש. נקרא לעיתים קרובות userinfo_endpoint במסמך Discovery.

היקפים: רשימה מופרדת בפסיקים של היקפים שספק ה-OP משתמש בהם כדי לספק מידע על המשתמש ל-Looker. אתם צריכים לכלול את היקף ההרשאה openid ואת כל היקפי ההרשאה שכוללים את המידע שנדרש ל-Looker, כולל כתובות אימייל, שמות משתמשים וכל מאפייני המשתמש שהוגדרו במופע Looker שלכם.

הגדרת מאפייני משתמשים

בקטע הזה, ממפים את הטענות של ספק הזהויות למאפייני המשתמש ב-Looker.

בקטע User Attribute Settings (הגדרות מאפייני משתמש), מזינים את שם הטענה של ספק ה-OP שמכילה את המידע המתאים לכל שדה. ההגדרה הזו מציינת ל-Looker איך למפות את הטענות האלה לפרטי המשתמש ב-Looker בזמן הכניסה. ל-Looker לא משנה איך בנויות התלונות, רק חשוב שהמידע על התלונות שמוזן כאן יהיה זהה לאופן שבו התלונות מוגדרות ב-OP שלכם.

תלונות רגילות

מערכת Looker דורשת שם משתמש וכתובת אימייל לצורך אימות משתמשים. בסעיף הזה צריך להזין את פרטי התביעה של בעל הזכויות:

Email Claim (תביעת בעלות על אימייל): התביעה שספק ה-OP משתמש בה לכתובות אימייל של משתמשים, כמו email.

טענת השם הפרטי: הטענה שספק ה-OP משתמש בה לשמות הפרטיים של המשתמשים, כמו given_name.

Last Name Claim: התלונה שספק ה-OP משתמש בה לשמות משפחה של משתמשים, כמו family_name.

שימו לב שחלק מספקי ה-OP משתמשים בתביעה אחת לשמות, במקום להפריד בין שם פרטי לשם משפחה. אם זה המקרה עם ה-OP שלכם, מזינים את התביעה שמאחסנת שמות בשני השדות First Name Claim (תביעה לשם פרטי) ו-Last Name Claim (תביעה לשם משפחה). מערכת Looker תשתמש בתוכן של כל משתמש עד הרווח הראשון כשם הפרטי, ובכל מה שאחרי הרווח כשם המשפחה.

זוגות של מאפיינים

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

כדי לשייך טענות למאפייני משתמשים תואמים ב-Looker, או כדי לנהל שיוכים קיימים, פועלים לפי השלבים הבאים:

  1. בקטע הגדרות מאפייני משתמש, לוחצים על הלחצן ניהול שיוכים כדי לפתוח את החלונית הצדדית ניהול שיוכים.
  2. בשדה תביעה, מזינים את התביעה שרוצים לשייך, כפי שזוהתה על ידי ה-OP. אפשר להזין שמות של תביעות ברשימה רק פעם אחת. אם רוצים לשייך טענת OpenID Connect לכמה מאפייני Looker, אפשר להזין כמה מאפיינים בשדה מאפייני משתמש ב-Looker.
  3. בשדה מאפייני משתמשים ב-Looker, מופיעה רשימה נפתחת של מאפייני משתמשים ב-Looker עבור המופע. בוחרים את השם של מאפיין המשתמש ב-Looker שרוצים להתאים לטענת OpenID Connect. אפשר לבחור כמה מאפייני משתמשים ב-Looker. צריך לבחור לפחות מאפיין משתמש אחד ב-Looker.
  4. מסמנים את התיבה חובה כדי לחסום ניסיונות כניסה של משתמשים שחסר להם ערך בשדה הזה של הטענה.
  5. לוחצים על הלחצן הוספת שיוך כדי להוסיף עוד שורת שיוך לרשימה. חוזרים על השלבים האלה כדי להוסיף עוד זוגות של טענות ומאפיינים.
  6. משמאל לכל שורה של צימוד מופיע סמל הסרת הצימוד. לוחצים על הסמל הזה כדי להסיר שיוך מאפיינים מהמופע.
  7. לוחצים על סמל הסגירה כדי לצאת מחלונית הצד ניהול שיוכים.
  8. בודקים את ההגדרה של OpenID Connect.
  9. מאמתים את ההגדרה של OpenID Connect, ובחלק התחתון של הדף OpenID Connect Authentication (אימות OpenID Connect), מסמנים את התיבה I have verified the OpenID Connect configuration (אימתתי את ההגדרה של OpenID Connect).
  10. לוחצים על הלחצן הפעלת OpenID Connect או עדכון ההגדרות של OpenID Connect כדי לשמור את ההתאמות בין התביעות לבין המאפיינים.

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

  • תפריט המסננים סינון הרשימה וסרגל החיפוש. אפשר להשתמש בכלים האלה כדי לחפש את הזיווגים שכבר נוספו למופע.
  • התפריט הנפתח של הצגת החלוקה לדפים. בתפריט הזה אפשר לבחור להציג 10, 25, 50 או 100 צמדים בכל דף.

תלונות מוטמעות

חלק מספקי הזהויות יכולים לכלול טענות 'מקוננות'. לדוגמה:

"zoneinfo": "America/Los Angeles",
"phone_number": "555-1235",
"address": {
  "street_address": "1234 Main Street",
  "locality": "Anyton",
  "region": "IL",
  "postal_code": "60609",
  "country": "US"
},

בדוגמה הקודמת, ההצהרה locality מוטמעת בהצהרה address. לגבי טענות מקוננות, מציינים את טענת ההורה ואת הטענות המקוננות, כשהן מופרדות בתו לוכסן ( / ). כדי להגדיר את Looker לטענת locality בדוגמה, צריך להזין address/locality.

קבוצות ותפקידים

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

שיקוף של קבוצות OpenID Connect מאפשר לכם להשתמש בספריית OpenID Connect שהוגדרה חיצונית כדי לנהל קבוצות ומשתמשים ב-Looker. כך תוכלו לנהל את חברי הקבוצה שלכם בכמה כלים של תוכנה כשירות (SaaS), כמו Looker, במקום אחד.

אם מפעילים את האפשרות Mirror OpenID Connect Groups (שיקוף קבוצות OpenID Connect),‏ Looker ייצור קבוצת Looker אחת לכל קבוצת OpenID Connect שמוצגת במערכת. אפשר לראות את קבוצות Looker האלה בדף קבוצות בקטע Admin ב-Looker.

קבוצות ותפקידים שמוגדרים כברירת מחדל

כברירת מחדל, המתג Mirror OpenID Connect Groups מושבת. במקרה כזה, אפשר להגדיר קבוצת ברירת מחדל למשתמשי OpenID Connect חדשים. בשדות New User Groups (קבוצות משתמשים חדשות) ו-New User Roles (תפקידי משתמשים חדשים), מזינים את השמות של קבוצות או תפקידים ב-Looker שרוצים להקצות למשתמשי Looker חדשים כשהם נכנסים ל-Looker בפעם הראשונה:

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

הפעלת קבוצות משתמשים תואמות ב-OpenID Connect

אם אתם משתמשים במופע של Looker (Google Cloud core), מומלץ להפעיל שיקוף קבוצות רק לשיטת האימות הראשית ולא להפעיל שיקוף קבוצות לאימות OAuth לגיבוי. אם מפעילים שיקוף קבוצות גם לשיטת האימות הראשית וגם לשיטת האימות המשנית, יתרחשו ההתנהגויות הבאות:

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

שלבים להפעלת קבוצות משוכפלות

כדי לשקף את קבוצות OpenID Connect ב-Looker, מפעילים את המתג Mirror OpenID Connect Groups (שיקוף קבוצות OpenID Connect). ההגדרות הבאות מוצגות ב-Looker:

בקשה לקבוצות משתמשים: מזינים את הבקשה שספק ה-OP משתמש בה כדי לאחסן שמות של קבוצות. לאחר מכן, מזינים את פרטי הקבוצה כדי להגדיר את הקבוצות הספציפיות של OpenID Connect שרוצים לשכפל ל-Looker בשדות שם הקבוצה המועדף / תפקידים / שם הקבוצה של OpenID Connect. חובה למפות את קבוצות OpenID Connect לקבוצות Looker.

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

  • שדה שם קבוצה מועדף. מזינים בשדה הזה שם מותאם אישית לקבוצה המשוכפלת. זה השם שיוצג בדף Groups בקטע Admin ב-Looker.

  • השדה OpenID Connect Group Name. מזינים בשדה הזה את קבוצת OpenID Connect. משתמשי OpenID Connect שנכללים בקבוצת OpenID Connect יתווספו לקבוצה המשוקפת ב-Looker.

  • שדה תפקיד. בשדה הזה, בוחרים תפקיד אחד או יותר ב-Looker שיוקצו לכל משתמש בקבוצה.

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

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

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

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

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

עריכה של קבוצות משוכפלות

אם תערכו קבוצה משוכפלת שהוגדרה קודם במסך הזה, ההגדרה של הקבוצה תשתנה אבל הקבוצה עצמה תישאר ללא שינוי. לדוגמה, אפשר לשנות את השם של קבוצה ב-Looker, וכך לשנות את האופן שבו הקבוצה מופיעה בדף Groups (קבוצות) ב-Looker, אבל לא לשנות את התפקידים שהוקצו ואת חברי הקבוצה. שינוי שם הקבוצה ב-OpenID Connect ישמור את שם הקבוצה ואת התפקידים, אבל החברים בקבוצה יוקצו מחדש על סמך המשתמשים שחברים בקבוצה החיצונית ב-OpenID Connect עם השם החדש.

כל שינוי שנעשה בקבוצה משוכפלת יחול על המשתמשים בקבוצה הזו בכניסה הבאה שלהם ל-Looker.

ניהול מתקדם של תפקידים

אם הפעלתם את המתג Mirror OpenID Connect Groups, ההגדרות האלה יוצגו ב-Looker. האפשרויות בקטע הזה קובעות את מידת הגמישות של אדמינים ב-Looker בהגדרת קבוצות ומשתמשים ב-Looker שמשוכפלים מ-OpenID Connect.

לדוגמה, אם רוצים שההגדרות של הקבוצות והמשתמשים ב-Looker יתאימו בדיוק להגדרות של OpenID Connect, צריך להפעיל את האפשרויות האלה. אם כל שלוש האפשרויות הראשונות מופעלות, אדמינים ב-Looker לא יכולים לשנות את החברות בקבוצות משוכפלות, והם יכולים להקצות תפקידים למשתמשים רק דרך קבוצות משוכפלות של OpenID Connect.

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

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

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

הקטע ניהול מתקדם של תפקידים כולל את האפשרויות הבאות:

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

אם האפשרות הזו מושבתת, אדמינים ב-Looker יכולים להקצות תפקידים ב-Looker ישירות למשתמשים ב-OpenID Connect, כאילו הם משתמשים שהוגדרו ישירות ב-Looker.

Prevent Direct Membership in non-OpenID Connect Groups (מניעת צירוף ישיר לקבוצות שאינן OpenID Connect): הפעלת האפשרות הזו מונעת ממנהלי Looker להוסיף משתמשי OpenID Connect ישירות לקבוצות מובנות ב-Looker. אם מותר לקבוצות משוכפלות של OpenID Connect להיות חברות בקבוצות מובנות של Looker, יכול להיות שמשתמשי OpenID Connect יישארו חברים בקבוצות הורה של Looker. משתמשים ב-OpenID Connect שהוקצו בעבר לקבוצות מובנות ב-Looker יוסרו מהקבוצות האלה בכניסה הבאה שלהם.

אם האפשרות הזו מושבתת, אדמינים ב-Looker יכולים להוסיף משתמשים ב-OpenID Connect ישירות לקבוצות מובנות ב-Looker.

Prevent Role Inheritance from non-OpenID Connect Groups: הפעלת האפשרות הזו מונעת מחברים בקבוצות משוכפלות של OpenID Connect לקבל בירושה תפקידים מקבוצות מובנות של Looker. משתמשים ב-OpenID Connect שקיבלו בעבר תפקידים בירושה מקבוצת Looker ברמת ההורה יאבדו את התפקידים האלה בכניסה הבאה שלהם.

אם האפשרות הזו מושבתת, קבוצות OpenID Connect משוכפלות או משתמשי OpenID Connect שנוספים כחברים בקבוצת Looker מובנית יקבלו בירושה את התפקידים שהוקצו לקבוצת Looker הראשית.

האימות מחייב תפקיד: אם האפשרות הזו מופעלת, משתמשים ב-OpenID Connect צריכים לקבל תפקיד. משתמשים ב-OpenID Connect שלא הוקצה להם תפקיד לא יוכלו להיכנס ל-Looker בכלל.

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

השבתת קבוצות משוכפלות של OpenID Connect

כדי להפסיק את השכפול של קבוצות OpenID Connect ב-Looker, משביתים את המתג Mirror OpenID Connect Groups. השבתת המתג מובילה להתנהגות הבאה:

  • כל קבוצת OpenID Connect משוכפלת ללא משתמשים נמחקת באופן מיידי.
  • כל קבוצת OpenID Connect משוכפלת שכן מכילה משתמשים מסומנת כקבוצה יתומה. אם אף משתמש בקבוצה הזו לא יתחבר לחשבון תוך 31 יום, הקבוצה תימחק. אי אפשר יותר להוסיף משתמשים לקבוצות יתומות של OpenID Connect או להסיר אותם מהן.

הגדרת אפשרויות ההעברה

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

כניסה חלופית למשתמשים ספציפיים

כשהאימות באמצעות OpenID Connect מופעל, הכניסה באמצעות כתובת אימייל וסיסמה ב-Looker תמיד מושבתת למשתמשים רגילים. האפשרות כניסה חלופית למשתמשים ספציפיים מאפשרת כניסה חלופית שמבוססת על כתובת אימייל באמצעות /login/email לאדמינים ולמשתמשים ספציפיים עם ההרשאה login_special_email.

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

ציון השיטה שמשמשת למיזוג משתמשי OpenID Connect עם חשבון Looker

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

  • שם משתמש וסיסמה ב-Looker (לא זמין ב-Looker (Google Cloud Core))
  • Google
  • ‫LDAP (לא זמין ב-Looker (Google Cloud Core))
  • SAML

אם יש לכם כמה מערכות אימות, אתם יכולים לציין בשדה הזה יותר ממערכת אחת למיזוג. ‫Looker יחפש משתמשים במערכות שמופיעות ברשימה לפי הסדר שבו הן מצוינות. לדוגמה, נניח שיצרתם משתמשים באמצעות כתובת אימייל וסיסמה ב-Looker, ואז הפעלתם LDAP, ועכשיו אתם רוצים להשתמש ב-OpenID Connect. בדוגמה הקודמת, Looker ימזג קודם לפי אימייל וסיסמה ואז לפי LDAP.

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

כדי לפתור את הבעיה של חשבונות כפולים, צריך למחוק את חשבונות האימייל הכפולים שלא נמצאים בשימוש מממשק המשתמש של האדמין. כדי להעניק למשתמש גישה לאימייל תוך שמירה על אותו חשבון OpenID Connect, האדמינים צריכים ליצור פרטי כניסה לאימייל ישירות בחשבון OpenID Connect הקיים באמצעות Looker API, ולא ליצור חשבון משתמש חדש ונפרד מממשק המשתמש של Admin.

מיזוג משתמשים ב-Looker (Google Cloud Core)‎

כשמשתמשים ב-Looker (Google Cloud core) וב-OpenID Connect, המיזוג פועל כמו שמתואר בקטע הקודם. עם זאת, אפשר לעשות זאת רק אם מתקיים אחד משני התנאים הבאים:

  • תנאי 1: משתמשים מבצעים אימות ב-Looker (ליבת Google Cloud) באמצעות הזהויות שלהם ב-Google דרך פרוטוקול OpenID Connect.

  • תנאי 2: לפני שבוחרים באפשרות המיזוג, צריך להשלים את שני השלבים הבאים:

    1. זהויות של משתמשים מאוחדים ב- Google Cloud באמצעות Cloud Identity.
    2. מגדירים אימות OAuth כשיטת האימות לגיבוי באמצעות משתמשים מאוחדים.

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

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

בדיקת אימות משתמשים

במהלך הגדרת התצורה הזו, לוחצים על הלחצן בדיקה כדי לבדוק את הגדרת OpenID Connect.

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

  • אם Looker הצליח לתקשר עם נקודות הקצה השונות ולאמת אותן
  • מעקב אחר התגובה של נקודת הקצה של האימות
  • פרטי המשתמש ש-Looker מקבל מנקודת הקצה של פרטי המשתמש
  • גרסאות מפוענחות וגרסאות גולמיות של טוקן הזהות שהתקבל

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

כדאי לדעת:

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

שמירת ההגדרות והחלתן

אחרי שמזינים את הפרטים וכל הבדיקות עוברות, מסמנים את התיבה I have confirmed the configuration above and want to enable applying it globally (אישרתי את ההגדרה שלמעלה ואני רוצה להחיל אותה באופן גלובלי) ולוחצים על Update Settings (עדכון ההגדרות) כדי לשמור.

פתרון בעיות

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

פתרון בעיות ב-OIDC במופעי Looker (Google Cloud Core) PSC

אם קיבלתם שגיאת 504 Upstream Request Timeout אחרי שחזרתם מדף הכניסה של ספק הזהויות במופע של Looker (Google Cloud core) עם Private Service Connect מופעל, בדרך כלל זה מצביע על כך שהמופע לא יכול להגיע לדומיין של ספק ה-OIDC החיצוני.

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

  1. הפעלת יציאה מבוקרת: מוסיפים את שמות הדומיין שמוגדרים במלואם (FQDN) שנדרשים לספק OIDC לרשימת ההיתרים Global FQDN כדי לוודא שיציאה מבוקרת מופעלת במופע. שימו לב שתהליכי OIDC כוללים לעיתים קרובות כמה דומיינים (כמו נקודות קצה של כניסה, הפניה או API) שצריך לאשר את כולם.
  2. זיהוי דומיינים חסרים: אם השגיאה נמשכת, צריך לצלם מעקב אחר הרשת (קובץ HAR) בדפדפן. מחפשים בקובץ ה-HAR שגיאות 504 כדי לזהות את שמות הדומיין המלאים שחסרים ומשתתפים בתהליך האימות.
  3. איפוס ההגדרה: אם נראה שההגדרות לא נכנסות לתוקף, אפשר לנסות לאפס את ההגדרה באמצעות השלבים הבאים:
    • משביתים באופן זמני את היציאה המבוקרת על ידי מחיקת שמות הדומיין המלאים הקיימים. א. משביתים באופן זמני את היציאה המבוקרת על ידי מחיקת שמות הדומיין המלאים הקיימים. ב. שומרים את המופע. ג. מפעילים מחדש את היציאה המבוקרת עם הרשימה המלאה של שמות הדומיין שמוגדרים במלואם (FQDN) שנדרשים.