הגדרות אדמין – אימות SAML

הדף SAML בקטע Authentication בתפריט Admin מאפשר להגדיר את Looker כך שיאמת משתמשים באמצעות Security Assertion Markup Language ‏ (SAML). בדף הזה מתואר התהליך הזה, ומופיעות בו הוראות לקישור קבוצות SAML לתפקידים ולהרשאות ב-Looker.

דרישות

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

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

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

SAML וספקי זהויות

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

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

Looker תומך בכניסה יזומה של IdP.

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

ב-Okta יש אפליקציית Looker, וזו הדרך המומלצת להגדיר את Looker ו-Okta ביחד.

הגדרת Looker בספק הזהויות

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

המידע שצריך לספק הוא כתובת ה-URL שדרכה אתם בדרך כלל ניגשים למופע של Looker באמצעות הדפדפן, ואחריה /samlcallback. לדוגמה: none https://instance_name.looker.com/samlcallback

או

https://looker.mycompany.com/samlcallback

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

https://instance_name.looker.com:9999/samlcallback

חשוב לדעת

חשוב לזכור:

• ‫Looker דורש SAML 2.0.
• אל תשביתו את האימות באמצעות SAML כשאתם מחוברים ל-Looker באמצעות SAML, אלא אם הגדרתם התחברות לחשבון חלופי. אחרת, אתם עלולים להינעל מחוץ לאפליקציה.
• ב-Looker אפשר להעביר חשבונות קיימים ל-SAML באמצעות כתובות אימייל שמגיעות מהגדרות קיימות של אימייל וסיסמה, או מ-Google Auth, מ-LDAP או מ-OIDC. בתהליך ההגדרה תוכלו לקבוע איך להעביר חשבונות קיימים.

תחילת העבודה

כדי להגדיר אימות SAML למופע Looker, בוחרים באפשרות SAML בקטע אימות בחלונית Admin (אדמין). בדף SAML Authentication, בוחרים באפשרות Configure SAML כדי לראות את אפשרויות ההגדרה הבאות.

הגדרות אימות SAML

כדי לאמת את ה-IdP, ב-Looker צריך להזין את כתובת ה-URL של ה-IdP, את המנפיק של ה-IdP ואת האישור של ה-IdP.

יכול להיות שה-IdP יציע מסמך XML של מטא-נתונים של IdP במהלך תהליך ההגדרה של Looker בצד ה-IdP. הקובץ הזה מכיל את כל המידע שנדרש בקטע SAML Auth Settings. אם יש לכם את הקובץ הזה, אתם יכולים להעלות אותו בשדה IdP Metadata, והשדות הנדרשים בקטע הזה יאוכלסו. אפשר גם למלא את השדות הנדרשים לפי הפלט שמתקבל במהלך ההגדרה בצד ספק הזהויות. אם מעלים את קובץ ה-XML, לא צריך למלא את השדות.

• מטא-נתונים של IdP (אופציונלי): מדביקים כאן את כתובת ה-URL הציבורית של מסמך ה-XML שמכיל את פרטי ה-IdP, או את הטקסט המלא של המסמך. מערכת Looker תנתח את הקובץ כדי לאכלס את שדות החובה.

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

• כתובת ה-URL של ה-IdP: כתובת ה-URL שאליה Looker יפנה כדי לאמת משתמשים. ב-Okta, הכתובת הזו נקראת Redirect URL (כתובת URL להפניה אוטומטית).

• ‫IdP Issuer: המזהה הייחודי של ספק ה-IdP. ב-Okta, השדה הזה נקרא External Key (מפתח חיצוני).

• אישור IdP: המפתח הציבורי שמאפשר ל-Looker לאמת את החתימה של התשובות מה-IdP.

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

• ישות SP/קהל IdP: השדה הזה לא נדרש על ידי Looker, אבל הרבה ספקי זהויות דורשים אותו. אם תזינו ערך בשדה הזה, הערך הזה יישלח ל-IdP בתור Entity ID של Looker בבקשות הרשאה. במקרה כזה, Looker יקבל רק תגובות הרשאה שהערך הזה מופיע בהן בתור Audience. אם ה-IdP דורש ערך Audience, צריך להזין את המחרוזת הזו כאן.

• ‫Allowed Clock Drift: מספר השניות המותר של סטיית השעון (ההפרש בחותמות הזמן בין ה-IdP ל-Looker). הערך הזה בדרך כלל יהיה ברירת המחדל 0, אבל יכול להיות שספקי זהויות מסוימים ידרשו מרווח נוסף כדי שההתחברות תצליח.

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

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

מאפיינים רגילים

תצטרכו לציין את המאפיינים הרגילים האלה:

• מאפיין אימייל: שם המאפיין שמשמש את ספק ה-IdP לכתובות האימייל של המשתמשים.

• מאפיין שם פרטי: שם המאפיין שבו ספק הזהויות משתמש לשמות הפרטיים של המשתמשים.

• LName Attr: שם המאפיין שמשמש את ספק ה-IdP לשמות משפחה של משתמשים.

התאמה בין מאפייני SAML למאפייני משתמש ב-Looker

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

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

1. מזינים את השם של מאפיין SAML בשדה SAML Attribute (מאפיין SAML) ואת השם של מאפיין המשתמש ב-Looker שרוצים לשייך לו בשדה Looker User Attributes (מאפייני משתמש ב-Looker).
2. אם רוצים לדרוש ערך מאפיין SAML כדי לאפשר למשתמש להתחבר, בוחרים באפשרות נדרש.
3. לוחצים על + וחוזרים על השלבים האלה כדי להוסיף עוד זוגות של מאפיינים.

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

1. בקטע הגדרות של מאפייני משתמשים, לוחצים על הכפתור ניהול התאמות כדי לפתוח את החלונית הצדדית ניהול התאמות.
2. בשדה Claim, מזינים את השם של מאפיין ה-SAML שרוצים להתאים. אפשר להזין כל שם של תלונה רק פעם אחת. אם רוצים לשייך טענה לכמה מאפיינים של Looker, אפשר להזין כמה מאפיינים בשדה מאפייני משתמש ב-Looker.
3. בשדה מאפייני משתמשים ב-Looker מופיעה רשימה נפתחת של מאפייני משתמשים ב-Looker עבור המופע. בוחרים את השם של מאפיין המשתמש ב-Looker שרוצים להתאים למאפיין SAML. אפשר לבחור כמה מאפייני משתמש ב-Looker לתביעה, אבל צריך לבחור לפחות מאפיין משתמש אחד ב-Looker.
4. אם רוצים לדרוש ערך מאפיין SAML כדי לאפשר למשתמש להיכנס, מסמנים את התיבה חובה.
5. לוחצים על הלחצן הוספת התאמה כדי להוסיף עוד שורה של התאמה לרשימה. חוזרים על השלבים האלה כדי להוסיף עוד זוגות של מאפיינים.
6. משמאל לכל שורה של התאמה מופיע הסמל delete הסרת ההתאמה. לוחצים על הסמל הזה כדי להסיר צמד מאפיינים מהמופע.
7. לוחצים על סמל הסגירה close כדי לצאת מהחלונית הצדדית ניהול השיוכים.
8. בודקים את הגדרת ה-SAML.
9. מאמתים את הגדרות ה-SAML, ובתחתית הדף אימות SAML, מסמנים את התיבה אימתתי את הגדרות ה-SAML.
10. לוחצים על הכפתור Enable SAML או Update SAML Settings כדי לשמור את ההתאמות של מאפייני המשתמשים ב-SAML.

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

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

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

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

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

אם מפעילים את האפשרות Mirror SAML Groups, המערכת של Looker תיצור קבוצת Looker אחת לכל קבוצת SAML שנוספת למערכת. אפשר לראות את הקבוצות האלה של Looker בדף Groups בקטע Admin ב-Looker. אפשר להשתמש בקבוצות כדי להקצות תפקידים לחברי הקבוצה, להגדיר אמצעי בקרת גישה לתוכן ולהקצות מאפייני משתמשים.

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

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

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

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

הפעלת קבוצות SAML מותאמות

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

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

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

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

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

• כמעט כל ספקי ה-IdP משתמשים בערך מאפיין יחיד כדי להקצות קבוצות, כמו שמוצג בטענת הנכוֹנוּת (assertion) של SAML לדוגמה: none <saml2:Attribute Name='Groups'> <saml2:AttributeValue >Everyone</saml2:AttributeValue> <saml2:AttributeValue >Admins</saml2:AttributeValue> </saml2:Attribute> במקרה הזה, בוחרים באפשרות Groups as values of single attributes (קבוצות כערכים של מאפיינים יחידים).

• חלק מספקי הזהויות משתמשים במאפיין נפרד לכל קבוצה, ואז דורשים מאפיין שני כדי לקבוע אם משתמש הוא חבר בקבוצה. דוגמה לטענת נכוֹנוּת (assertion) של SAML שמציגה את המערכת הזו: none <saml2:Attribute Name='group_everyone'> <saml2:AttributeValue >yes</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute Name='group_admins'> <saml2:AttributeValue >no</saml2:AttributeValue> </saml2:Attribute> במקרה הזה, בוחרים באפשרות קבוצות כמאפיינים נפרדים עם ערך חברות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בקטע Advanced Role Management מופיעות האפשרויות הבאות:

Prevent Individual SAML Users from Receiving Direct Roles: הפעלת האפשרות הזו מונעת מאדמינים ב-Looker להקצות תפקידים ב-Looker ישירות למשתמשי SAML. משתמשי SAML יקבלו תפקידים רק דרך החברות שלהם בקבוצות. אם משתמשי SAML יכולים להיות חברים בקבוצות מובנות (לא משוקפות) ב-Looker, הם עדיין יכולים לקבל את התפקידים שלהם בירושה גם מקבוצות SAML משוקפות וגם מקבוצות מובנות ב-Looker. תפקידים שהוקצו בעבר ישירות למשתמשי SAML יוסרו מהם כשהם יתחברו בפעם הבאה.

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

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

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

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

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

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

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

השבתת שיקוף קבוצות SAML

אם רוצים להפסיק את השכפול של קבוצות SAML ב-Looker, משביתים את המתג Mirror SAML Groups (שכפול קבוצות SAML). השבתת המתג גורמת להתנהגות הבאה:

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

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

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

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

כדאי להפעיל את האפשרות הזו כגיבוי במהלך הגדרת האימות באמצעות SAML, למקרה שיתרחשו בעיות בהגדרת SAML בהמשך, או אם צריך לתמוך במשתמשים מסוימים שאין להם חשבונות בספריית SAML. אי אפשר להשבית או להסתיר את נקודת הקצה /login/email באופן מלא, כי היא פועלת כמנגנון חלופי קריטי כדי להבטיח שאדמינים יוכלו לקבל גישה מחדש אם הגדרת ה-SAML הראשית נכשלת או מוגדרת בצורה שגויה. אם אדמין ננעל בטעות מחוץ לחשבון שלו בזמן הגדרת רשימת כתובות ה-IP המותרות, הוא יכול לפנות ל Google Cloud תמיכה כדי לשחזר את החשבון.

הסרת פרטי כניסה מדור קודם של משתמשי SAML

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

כדי למחוק את פרטי הכניסה לאימייל של משתמש ספציפי, משתמשים בנקודת הקצה DELETE /users/{user_id}/credentials_email ב-Looker API.

כדי למחוק פרטי כניסה של אימייל בכמות גדולה, אתם יכולים להשתמש בסקריפטים של Looker API או בכלים לניהול משתמשים בכמות גדולה (כמו Looker Admin Power Pack בקוד פתוח).

מציינים את השיטה שבה משתמשי SAML ימוזגו לחשבון Looker

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

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

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

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

טיפול בשינויים בדומיין של ספק הזהויות

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

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

1. מעדכנים את המאפיין Email של משתמשי Looker לכתובת האימייל של הדומיין החדש.
2. מוודאים שהאפשרות Merge Users Using (מיזוג משתמשים באמצעות) מוגדרת כך שתאפשר מיזוג לפי כתובת אימייל.

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

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

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

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

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

אם המכונה שלכם לא עומדת באחד משני התנאים האלה, האפשרות Merge Users Using לא תהיה זמינה.

במהלך המיזוג, Looker (Google Cloud core)‎ יחפש רשומות של משתמשים עם אותה כתובת אימייל בדיוק.

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

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

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

טיפים:

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

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

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

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

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

זוהי פעולת ברירת המחדל אם למשתמש עדיין אין סשן Looker פעיל.

אם רוצים שהמשתמשים ייכנסו ישירות למופע Looker אחרי שספק הזהויות (IdP) יאמת אותם, ויעקפו את הדף Log In, מפעילים את האפשרות Bypass Login Page בקטע Login Behavior.

אם אתם משתמשים ב-Looker (Original), צריך להפעיל את התכונה Bypass Login Page ב-Looker. כדי לעדכן את הרישיון שלכם לתכונה הזו, אתם יכולים לפנות ל Google Cloud מומחה מכירות או לפתוח בקשת תמיכה. אם אתם משתמשים ב-Looker (Google Cloud core), האפשרות Bypass Login Page זמינה באופן אוטומטי אם SAML משמש כשיטת האימות הראשית, והיא מושבתת כברירת מחדל.

כשההגדרה Bypass Login Page (דילוג על דף הכניסה) מופעלת, רצף הכניסה של המשתמש הוא כזה:

1. המשתמש מנסה להתחבר לכתובת URL ב-Looker (לדוגמה, instance_name.looker.com).

2. מערכת Looker בודקת אם למשתמש כבר יש סשן פעיל. כדי לעשות את זה, Looker משתמשת בקובץ ה-Cookie‏ AUTH-MECHANISM-COOKIE כדי לזהות את שיטת ההרשאה שבה המשתמש השתמש בסשן האחרון שלו. הערך הוא תמיד אחד מהבאים: saml,‏ ldap,‏ oidc,‏ google או email.

3. אם למשתמש יש סשן פעיל, הוא מועבר לכתובת ה-URL המבוקשת.

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

5. אם האימות ב-IdP הצליח, Looker מאמת את הצהרות ה-SAML, מאשר את האימות, מעדכן את פרטי המשתמש ומעביר את המשתמש לכתובת ה-URL המבוקשת, בלי להציג את הדף Log In.

6. אם המשתמש לא יכול להיכנס ל-IdP, או אם אין לו הרשאה מה-IdP להשתמש ב-Looker, אז בהתאם ל-IdP, הוא יישאר באתר של ה-IdP או יופנה לדף Log In של Looker.

פתרון בעיות

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

כשלים בהקצאת הרשאות בזמן אמת בלבד (JIT) ב-SAML וקונפליקטים במיזוג

יכול להיות שהמשתמשים יראו את השגיאה "הדף הזה לא קיים או שאין לך הרשאה לצפות בו" במהלך הקצאת הרשאות בזמן אמת בלבד (JIT) ב-SAML לתצוגות מוטמעות של Looker. בחלונית Users, יכול להיות שיופיע שהמשתמשים האלה אף פעם לא התחברו באמצעות SAML, ושהאישור הפעיל שלהם הוא Email במקום SAML. בנוסף, אדמינים שמנסים להשתמש בפקודה sudo בתור המשתמש יראו את המסך 'עליך לעדכן את החשבון שלך'.

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

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

1. בחלונית Admin ב-Looker, עוברים אל Admin > SAML.
2. בקטע New User Options (או Migration options, בהתאם לגרסת Looker), מוודאים שההגדרה Merge Users Using מוגדרת ל-Looker Email/Password.
3. אם המשתמש הרלוונטי כבר קיים עם פרטי כניסה של אימייל ואין לו תוכן קריטי מצורף, מוחקים את חשבון המשתמש הקיים שמבוסס על אימייל. המחיקה הזו מאפשרת ל-Looker, בכניסה הבאה של המשתמש, ליצור רשומה חדשה של המשתמש שמבוססת רק על טענת הנכונות (assertion) של SAML.

תגובת SAML חורגת מהמגבלה

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

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

במופעי Looker שמתארחים בצד הלקוח, אפשר להגדיר את הגודל המקסימלי של תגובת SAML במספר בייטים באמצעות משתנה הסביבה MAX_SAML_RESPONSE_BYTESIZE. לדוגמה:

export MAX_SAML_RESPONSE_BYTESIZE=500000

ערך ברירת המחדל של הגודל המקסימלי של תגובת SAML הוא 250,000 בייטים.

חסרים מאפייני קבוצת SAML ב-Okta

צריך להגדיר את אפליקציית ספק הזהויות של Okta כך שתכלול את המאפיין Groups בטענות הנכוֹנוּת (assertions) של SAML. מקרה לדוגמה:

<saml2:Attribute Name='Groups'>

כדי לוודא שהמאפיין Groups קיים ושהפורמט שלו נכון, צריך לאמת את מטען ה-SAML ב-Looker באמצעות האפשרות Test SAML Authentication.