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

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

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

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

דרישות

‫Looker מציג את הדף OpenID Connect בקטע Authentication בתפריט Admin רק אם מתקיימים התנאים הבאים:

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

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

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

• כדאי להשתמש באפשרות Alternate Login for Specified Users כדי לאפשר לאדמינים של Looker לגשת ל-Looker בלי OpenID Connect.
• אל תשביתו את האימות באמצעות OpenID Connect בזמן שאתם מחוברים ל-Looker באמצעות OpenID Connect, אלא אם הגדרתם כניסה לחשבון חלופי. אחרת, אתם עלולים להינעל מחוץ לאפליקציה.
• Looker יכול להעביר חשבונות קיימים ל-OpenID Connect באמצעות כתובות אימייל שמגיעות מהגדרות נוכחיות של אימייל וסיסמה, LDAP,‏ SAML או Google Auth. תוכלו להגדיר את זה בתהליך ההגדרה.
• ‫Looker תומך באימות OpenID Connect רק באמצעות ההרשאה באמצעות קוד של OpenID Connect. אין תמיכה בתהליכי קוד אחרים.
• המפרט של OpenID Connect כולל מנגנון Discovery אופציונלי. ‫Looker לא תומך במנגנון הזה, ולכן צריך לספק כתובות URL מפורשות בקטע OpenID Connect Auth Settings, כמו שמתואר במאמר הגדרת הגדרות האימות של OpenID Connect.
• אלה דרישות מוקדמות נוספות להפעלת OpenID Connect במופע של Looker (Google Cloud core) שמשתמש בחיבורים פרטיים:
  • צריך להגדיר את Cloud Router כך שיפיץ את הנתיבים של רשת ה-VPC למכונת Looker (Google Cloud core) (לדוגמה, הגדרת נתיבים מותאמים אישית לפרסום).
  • צריך להגדיר קבוצת נקודות קצה ברשת האינטרנט (NEG) כדי לאפשר למופע של חיבורים פרטיים ב-Looker (Google Cloud core) לנתב תעבורה לספק הזהויות החיצוני.

הגדרת OpenID Connect

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

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

הגדרת Looker ב-OP

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

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

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

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

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

הקטע הבא הוא דוגמה למסמך 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 של ספק ה-OIDC, מספק ה-OIDC או מצוות האימות הפנימי שלכם כדי להזין את הגדרות החיבור בשדות הבאים:

‫Identifier: מזהה הלקוח הייחודי למופע Looker שלכם. השם הזה אמור להגיע מספק ה-OP.

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

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

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

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

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

‫User Info URL (כתובת ה-URL של פרטי המשתמש): כתובת ה-URL שבה Looker יאחזר פרטי משתמש מפורטים. במסמך Discovery, השדה הזה נקרא בדרך כלל userinfo_endpoint.

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

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

בקטע הזה נסביר איך למפות את ההצהרות של ספק הזהויות למאפייני משתמש ב-Looker.

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

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

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

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

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

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

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

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

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

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

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

החלונית הצדדית Manage Pairings כוללת גם את הכלים הבאים:

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

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

חלק מה-OPs יכולים לכלול תלונות "מקוננות". לדוגמה:

"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, המערכת של Looker תיצור קבוצת Looker אחת לכל קבוצת OpenID Connect שנוספת למערכת. אפשר לראות את קבוצות Looker האלה בדף Groups בקטע Admin ב-Looker.

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

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

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

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

הפעלת קבוצות OpenID Connect מקבילות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

עריכת קבוצות מסונכרנות

אם עורכים קבוצה משוכפלת שהוגדרה בעבר במסך הזה, ההגדרה של הקבוצה תשתנה אבל הקבוצה עצמה תישאר ללא שינוי. לדוגמה, אפשר לשנות את השם של קבוצה ב-Looker, וכך לשנות את האופן שבו הקבוצה מופיעה בדף Groups ב-Looker, אבל לא לשנות את התפקידים שהוקצו ואת חברי הקבוצה. אם תשנו את שם הקבוצה ב-OpenID Connect, שם הקבוצה והתפקידים יישמרו, אבל החברים בקבוצה יוקצו מחדש על סמך המשתמשים שחברים בקבוצה החיצונית ב-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 שבהם הוגדרו קבוצות משתמשים משוכפלות, האפשרויות האלה מופעלות כברירת מחדל.

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

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

Prevent Individual OpenID Connect Users from Receiving Direct Roles (מניעת הקצאת תפקידים ישירים למשתמשי 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.

מניעת ירושת תפקידים מקבוצות שאינן OpenID Connect: הפעלת האפשרות הזו מונעת מחברים בקבוצות 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 ממליצה להפעיל את האפשרות Alternate Login ולספק אסטרטגיית מיזוג למשתמשים קיימים.

התחברות חלופית למשתמשים שצוינו

הערה: כניסה חלופית לא זמינה ל-Looker ‏ (Google Cloud Core). שיטת האימות לגיבוי שמוגדרת כברירת מחדל היא OAuth.

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

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

הערה: אם משתמש אימת את הזהות שלו במכונה של Looker רק באמצעות OpenIP Connect, אפשר להפעיל התחברות חלופית רק באמצעות Looker API. כדי ללמוד איך להפעיל התחברות חלופית באמצעות Looker API, אפשר לעיין בדף התיעוד הפעלת אפשרות ההתחברות החלופית.

צריך לציין את השיטה שבה משתמשים כדי למזג משתמשי 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, האפשרות הזו תחבר את המשתמש לחשבון הקיים שלו על ידי איתור החשבון עם כתובת אימייל תואמת. אם למשתמש אין חשבון קיים, המערכת תיצור חשבון משתמש חדש.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

טיפים:

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

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

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

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

התנהגות המשתמשים בהתחברות

כשמשתמש מנסה להיכנס למכונה של Looker באמצעות OpenID Connect‏ (OIDC), ‏ Looker נפתח בדף Log In. המשתמש צריך ללחוץ על הכפתור אימות כדי להתחיל את האימות באמצעות OIDC.

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

פתרון בעיות

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

פתרון בעיות ב-OIDC במופעים של Looker (Google Cloud Core)‎

אם נתקלתם בבעיות בחיבור או בזמן קצוב לתפוגה כשמגדירים או בודקים אימות OIDC במכונה של Looker (Google Cloud core) (למשל שגיאות 504 Upstream Request Timeout, שגיאות HttpClient:ConnectTimeoutError execution expired, חוסר בנתיבי רשת של תעבורת נתונים יוצאת מבוקרת או שגיאות מטעות של אי התאמה של URI להפניה אוטומטית), כדאי לעיין במאמר פתרון בעיות ברשת של Looker (Google Cloud core).