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

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

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

דרישות

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

  • יש לכם הרשאת אדמין.
  • המכונה של Looker (המקורית) מופעלת לשימוש ב-OpenID Connect. כדי להפעיל את OpenID Connect, פנו לאיש ניהול החשבון שלכם.
  • מכונה של 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. יכול להיות שספק הזהויות יקרא לזה Redirect URI או Login Redirect URI, או בשמות אחרים. באתר של ספק הזהויות, מספקים לספק הזהויות את כתובת ה-URL שבה בדרך כלל ניגשים למכונה של Looker בדפדפן, ואחריה /openidconnect. לדוגמה, https://instance_name.looker.com/openidconnect.

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

כדי להגדיר את Looker לאימות באמצעות OpenID Connect, צריך את הפרטים הבאים מה-OP:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תביעת שם משפחה: התביעה שבה ספק ה-OIDC משתמש לשמות המשפחה של המשתמשים, למשל family_name.

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

צמדי מאפיינים

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

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

  1. בקטע הגדרות של מאפייני משתמשים, לוחצים על הכפתור ניהול התאמות כדי לפתוח את החלונית הצדדית ניהול התאמות.
  2. בשדה תביעה, מזינים את התביעה שרוצים להתאים, כפי שזוהתה על ידי ה-OP. אפשר להזין שמות של תביעות ברשימה רק פעם אחת. אם רוצים לשייך הצהרה של OpenID Connect לכמה מאפיינים של Looker, אפשר להזין כמה מאפיינים בשדה Looker User Attributes.
  3. בשדה Looker User Attributes מופיעה רשימה נפתחת של מאפייני המשתמשים ב-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. לוחצים על הכפתור Enable OpenID Connect או Update OpenID Connect Settings כדי לשמור את צמדי ההצהרות והמאפיינים.

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

  • תפריט הסינון רשימת מסננים ושורת החיפוש. אתם יכולים להשתמש בכלים האלה כדי לחפש את הצמדים שכבר נוספו למכונה שלכם.
  • התפריט הנפתח 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 מקבילות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מניעת חברות ישירה בקבוצות שאינן 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 מיותמות או להסיר אותם מהן.

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

כמו שמוסבר בקטע הזה, מומלץ להפעיל את האפשרות Alternate Login (התחברות חלופית) ולספק אסטרטגיית מיזוג למשתמשים קיימים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

טיפים:

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

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

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

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

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

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

פתרון בעיות

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

פתרון בעיות ב-OIDC במכונות של Looker (Google Cloud core)

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