שימוש ב-Google OAuth לאימות משתמשים ב-Looker (Google Cloud Core)‎

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

משתמשים ב-OAuth של Google בשילוב עם ניהול זהויות והרשאות גישה (IAM) כדי לאמת משתמשים ב-Looker (הליבה של Google Cloud).

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

אם שיטה אחרת היא שיטת האימות העיקרית, אימות OAuth של Google הוא שיטת האימות לגיבוי שמוגדרת כברירת מחדל.

אימות והרשאה באמצעות OAuth ו-IAM

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

תפקיד IAM	אימות	הרשאה
משתמש במופע Looker (roles/looker.instanceUser)	אפשר להיכנס למופעים של Looker (Google Cloud Core)‎	בכניסה הראשונה ל-Looker (הליבה של Google Cloud), המשתמש מקבל את ברירת המחדל של התפקידים ב-Looker שמוגדרת בתפקידים למשתמשים חדשים. אין גישה למשאבים של Looker ‏ (שירות הליבה של Google Cloud) במסוף Google Cloud .
משתמש עם הרשאת צפייה ב-Looker (roles/looker.viewer)	אפשר להיכנס למופעים של Looker (Google Cloud Core)‎	בכניסה הראשונה ל-Looker (הליבה של Google Cloud), המשתמש מקבל את ברירת המחדל של התפקידים ב-Looker שמוגדרת בתפקידים למשתמשים חדשים. יכולים לראות את רשימת המופעים של Looker (Google Cloud core) ואת פרטי המופעים במסוף Google Cloud
אדמין ב-Looker‏ (roles/looker.admin)	אפשר להיכנס למופעים של Looker (Google Cloud Core)‎	בכניסה הראשונה ל-Looker (הליבה של Google Cloud), המשתמש מקבל את ברירת המחדל של התפקידים ב-Looker שמוגדרת בתפקידים למשתמשים חדשים. בכל התחברות ל-Looker (Google Cloud core) שנעשית באמצעות OAuth ראשי או OAuth לגיבוי, ובכל פעם שהמשתמש מבצע קריאה ל-Looker API, התפקיד הזה (או תפקיד מותאם אישית שכולל את ההרשאה looker.instances.update) מעניק גם את התפקיד Admin via IAM בתוך המופע. התפקיד אדמין דרך IAM כולל את כל ההרשאות והיכולות של התפקיד אדמין ב-Looker. אי אפשר להסיר את התפקיד הזה או להקצות אותו מחדש במופע Looker (Google Cloud core). כדי להסיר את התפקיד אדמין דרך IAM, צריך להקצות מחדש את הסוכן לתפקיד IAM אחר מלבד אדמין Looker ‏ (roles/looker.admin). שינויים בתפקידי IAM מסונכרנים אוטומטית עם מופע Looker ‏ (Google Cloud core), גם אם המשתמש מתחבר באמצעות ספק זהויות של צד שלישי אחרי השינוי. מידע נוסף זמין בקטע תפקיד אדמין ב-Looker לעומת תפקיד אדמין ב-Looker באמצעות IAM. כל עוד טוקן הרענון של OAuth של המשתמש תקף, התפקיד של המשתמש מופיע כאדמין דרך IAM ב-Looker (Google Cloud core), גם אם המשתמש נכנס מאוחר יותר באמצעות ספק זהויות של צד שלישי. אם טוקן הרענון של OAuth פג או בוטל, המשתמש צריך להשתמש ב-OAuth כדי להיכנס שוב למופע ולקבל שוב את התפקיד אדמין דרך IAM. יכולים לבצע את כל משימות האדמין ב-Looker (ליבת Google Cloud) במסוף Google Cloud

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

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

חשבונות Looker (Google Cloud Core) נוצרים בזמן הכניסה הראשונה למופע Looker (Google Cloud Core).

תפקיד אדמין ב-Looker לעומת תפקיד אדמין ב-Looker דרך IAM

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

יש שני תפקידים במופע Looker (Google Cloud core) שמשתמשים בקבוצת הרשאות האדמין ומעניקים את אותן הרשאות אדמין במופע. בטבלה הבאה מסוכמים נקודות הדמיון וההבדלים בין שני התפקידים.

מאפיין (property)	תפקיד אדמין ב-Looker	ניהול באמצעות תפקיד Looker ב-IAM
מקור מהימן	ההרשאה ניתנה על ידי אדמין אחר במופע Looker (Google Cloud Core)‎	מקושר ישירות לתפקיד האדמין ב-IAM של Looker
האם אפשר להוסיף או להסיר אותם במופע של Looker (Google Cloud Core)?	כן	לא
אפשר להוסיף או להסיר אותם באמצעות IAM?	לא	כן
הרשאות ב-Looker (Google Cloud Core)‎	כל ההרשאות	כל ההרשאות
הרשאות במסוף Google Cloud	ללא	גישה מלאה לכל המשאבים של Looker (Google Cloud Core)‎
אימות התפקיד	באופן רציף במכונה של Looker (Google Cloud Core)‎	בכל התחברות למכונה של Looker (Google Cloud Core)‎ ובכל קריאה ל-Looker API. יכול להיות שיחלפו כמה דקות עד שהשינויים בתפקיד עם IAM יופצו.
היקף	מופע Looker (Google Cloud Core)‎ ספציפי	כל המכונות של Looker (Google Cloud Core)‎ ב Google Cloud פרויקט

משתמש יכול לקבל גם את התפקיד אדמין וגם את התפקיד אדמין דרך IAM ב-Looker. לכן, אם רוצים לבטל הרשאות אדמין, צריך להסיר גם את תפקיד ה-IAM וגם את התפקיד Admin במופע Looker (Google Cloud core).

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

הגדרת OAuth במופע Looker (Google Cloud Core)

במופע של Looker (Google Cloud core), אפשר להגדיר חלק מהגדרות Google OAuth בדף Google Authentication שבקטע Authentication בתפריט Admin. צריכה להיות לכם הרשאת אדמין ב-Looker.

מיזוג חשבונות משתמשים

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

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

• SAML
• OIDC

אם יש לכם יותר ממערכת אחת, אתם יכולים לציין בשדה הזה יותר ממערכת אחת למיזוג. ‫Looker (Google Cloud core) יחפש משתמשים במערכות שמופיעות ברשימה לפי הסדר שבו המערכות צוינו. לדוגמה, אם יצרתם משתמשים באמצעות OIDC ואחר כך השתמשתם ב-SAML, כשמשתמש ינסה להתחבר באמצעות OAuth בפעם הראשונה, מערכת Looker (Google Cloud core) תחפש את המשתמש באמצעות OIDC. אם לא יימצא משתמש תואם באמצעות OIDC, המערכת תחפש את המשתמש באמצעות SAML.

אם לא רוצים ש-Looker (ליבת Google Cloud) ימזג משתמשים, משאירים את השדה הזה ריק.

שיקוף של קבוצות Google

הערה: אין תמיכה בשיקוף קבוצות של Google OAuth במופעים של Looker ‏ (Google Cloud Core) שמופעל בהם מצב תאימות ל-FIPS.

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

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

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

התפקיד אדמין דרך IAM ב-Looker, שמוענק באופן אוטומטי למשתמשים שיש להם את התפקיד אדמין ב-Looker במערכת IAM, מבטל את שיקוף הקבוצות. למשתמשים עם התפקיד Looker Admin במערכת IAM מוקצה באופן אוטומטי התפקיד Admin via IAM ב-Looker (Google Cloud core), ללא קשר לחברות שלהם בקבוצות. בנוסף, המשתמשים האלה יוקצו לקבוצות משוכפלות ויקבלו תפקידים וגישה באמצעות תהליך השכפול הרגיל.

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

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

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

כדי להפעיל את שיקוף הקבוצה:

1. במסוף Google Cloud , מפעילים את Cloud Identity API ב Google Cloud פרויקט שמכיל את לקוח OAuth. כדי להפעיל ממשקי API, צריך להיות לכם תפקיד IAM של אדמין לשימוש בשירותים (roles/serviceusage.serviceUsageAdmin).

   הפעלת ה-API

2. במסוף Google Cloud , מעדכנים את מסך ההסכמה של לקוח OAuth כדי להוסיף את היקף ההרשאות https://www.googleapis.com/auth/cloud-identity.groups.readonly. כדי להוסיף היקפי הרשאות, צריך את הרשאת ה-IAM‏ clientauthconfig.clients.update. כדי לעדכן את מסך בקשת ההסכמה:

   • עוברים ללקוח OAuth.
   • בוחרים בדף גישה לנתונים.
   • לוחצים על הלחצן הוספה או הסרה של היקפים. תיפתח החלונית Update selected scopes (עדכון ההיקפים שנבחרו).
   • מחפשים את ההיקף https://www.googleapis.com/auth/cloud-identity.groups.readonly ומסמנים את תיבת הסימון שלידו.
   • לוחצים על הלחצן עדכון כדי להוסיף את ההיקף.

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

     זהירות: אם השדה User Type בלקוח OAuth מוגדר כ-External, צריך להשלים אימות של היקף הרשאות מוגבל עבור אפליקציית OAuth. עד שאפליקציית OAuth תאומת על ידי Google, המשתמשים יוכלו להיכנס, אבל תוצג להם הודעת אזהרה במהלך תהליך הכניסה. הסיבה לכך היא ש-Cloud Identity API הוא היקף רגיש.

3. במופע Looker (Google Cloud core), מעבירים את המתג Mirror Google Groups למצב מופעל בדף Google Authentication. המתג הזה מושבת כברירת מחדל. ממלאים את השדות הבאים:

   • בשדה Looker Group Name (שם קבוצת Looker), מוסיפים שם לקבוצת Looker. זה השם שיופיע בדף Groups ב-Looker (Google Cloud core).
   • בשדה מזהה קבוצת Google, מזינים את השם או כתובת האימייל של קבוצת Google שרוצים לשכפל.
   • בשדה תפקיד, מזינים את התפקיד או התפקידים ב-Looker שרוצים להקצות לחברי הקבוצה.

‫Looker (Google Cloud core) ייצור קבוצת Looker אחת לכל קבוצת Google שנוספה לדף Google Authentication. אפשר לראות את קבוצות Looker האלה בדף Groups ב-Looker (Google Cloud Core).

הערה: ‏ Looker (Google Cloud core) מאחזר רק חברות ישירה של המשתמש בקבוצה. מיפוי של חברויות טרנזיטיביות או היררכיות לא יפעל.

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

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

אם עורכים את השדות Custom name (שם בהתאמה אישית) או Role (תפקיד) שמוקצים לקבוצה בדף Google Authentication (אימות Google), זה משנה את האופן שבו השם של קבוצת Looker המשוכפלת מופיע בדף Groups (קבוצות) ב-Looker (Google Cloud core) או את התפקידים שמוקצים לקבוצה, אבל זה לא משנה את חברי הקבוצה.

אם משנים את השם או את האימייל בשדה Google Group ID בדף Google Authentication למזהה של קבוצת Google חדשה, חברי הקבוצה המשוכפלת ב-Looker ישתנו לחברים בקבוצת Google החדשה, אבל השם והתפקידים של הקבוצה יישארו כפי שהוגדרו בדף Google Authentication.

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

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

אם רוצים להפסיק את השכפול של קבוצות Google ב-Looker (Google Cloud Core), צריך להשבית את המתג Mirror Google Groups (שכפול קבוצות Google) בדף Google Authentication (אימות Google) במופע של Looker (Google Cloud Core). השבתת המתג גורמת להתנהגות הבאה:

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

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

אם המתג Mirror Google Groups (שיקוף קבוצות Google) מופעל, ההגדרות של Advanced Role Management (ניהול מתקדם של תפקידים) מוצגות בדף Google Authentication (אימות Google). האפשרויות בקטע הזה קובעות את מידת הגמישות של מנהלי Looker בהגדרת קבוצות ומשתמשים ב-Looker שמשוכפלים מ-Google.

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

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

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

במופע של Looker ‏ (שירות הליבה של Google Cloud), האפשרויות האלה מושבתות כברירת מחדל.

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

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

  הערה: תפקיד Looker‏ Admin via IAM, שמוענק באופן אוטומטי למשתמשים עם תפקיד ה-IAM‏ Looker Admin, מבטל את האפשרות Prevent individual Google users from receiving direct roles. משתמשים עם תפקיד אדמין ב-Looker ב-IAM שומרים על תפקיד אדמין דרך IAM ב-Looker, בלי קשר למצב של האפשרות הזו. עם זאת, הפעלת האפשרות הזו מונעת מאדמינים ב-Looker להקצות תפקידים באופן ישיר.

  אם האפשרות הזו מושבתת, אדמינים ב-Looker יכולים להקצות תפקידים ב-Looker ישירות למשתמשי Google במופע Looker (ליבת Google Cloud).

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

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

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

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

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

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

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

הגדרת תפקיד ברירת מחדל ב-Looker

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

אם המתג Mirror Google Groups מושבת, ההגדרה Roles for new users מופיעה בדף Google Authentication. ההגדרה הזו מאפשרת לכם להגדיר את תפקיד ברירת המחדל ב-Looker שיוקצה לחשבונות משתמשים עם תפקיד IAM של משתמש במופע Looker ‏ (roles/looker.instanceUser) או עם תפקיד IAM של צופה ב-Looker ‏ (roles/looker.viewer) בכניסה הראשונה שלהם למופע Looker (ליבת Google Cloud). כדי להגדיר תפקיד ברירת מחדל, פועלים לפי השלבים הבאים:

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

תפקידי אדמין לא יכולים להיות תפקידים שמוגדרים כברירת מחדל. בכניסה הראשונה לחשבונות משתמשים עם תפקיד אדמין ב-IAM‏ (roles/looker.admin) ב-Looker, בנוסף לתפקיד שנבחר בהגדרה תפקידים למשתמשים חדשים, תוענק להם הרשאת אדמין דרך IAM ב-Looker.

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

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

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

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

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

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

הוספת משתמשים למופע של Looker (Google Cloud Core)‎

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

אחרי יצירת מופע של Looker (Google Cloud core), אפשר להוסיף משתמשים דרך IAM. כדי להוסיף משתמשים, פועלים לפי השלבים הבאים:

1. צריך לוודא שיש לכם את התפקיד אדמין IAM בפרויקט או תפקיד אחר שמאפשר לכם לנהל את הגישה ב-IAM.

2. עוברים אל Google Cloud פרויקט המסוף שבו נמצאת מכונת Looker (Google Cloud core).

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

3. עוברים לקטע IAM & Admin > IAM במסוף Google Cloud .

4. לוחצים על הענקת גישה.

5. בקטע Add principals, מוסיפים אחד או יותר מהפריטים הבאים:

   • כתובת האימייל בחשבון Google
   • קבוצה ב-Google
   • דומיין Google Workspace

6. בקטע Assign roles, בוחרים אחד מתפקידי ה-IAM המוגדרים מראש של Looker (Google Cloud core) או תפקיד בהתאמה אישית שהוספתם.

7. לוחצים על Save.

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

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

צריך להקצות הרשאות לכל המשתמשים באמצעות השלבים של IAM שמתוארים למעלה, עם יוצא מן הכלל אחד: אפשר ליצור חשבונות שירות לשימוש ב-Looker API בלבד במופע של Looker (Google Cloud core).

כניסה ל-Looker (Google Cloud Core)‎ באמצעות OAuth

בפעם הראשונה שהמשתמשים נכנסים, הם מתבקשים להיכנס באמצעות חשבון Google שלהם. כל משתמש צריך להשתמש באותו חשבון שאדמין Looker ציין בשדה Add principals כשנתן לו גישה. המשתמשים יראו את מסך ההסכמה ל-OAuth שהוגדר במהלך יצירת לקוח OAuth. אחרי שהמשתמשים מאשרים את מסך ההסכמה, החשבונות שלהם נוצרים במופע Looker (ליבת Google Cloud) והם מחוברים.

אחרי כן, המשתמשים יתחברו אוטומטית ל-Looker (ליבת Google Cloud), אלא אם ההרשאה שלהם תפוג או תבוטל על ידי המשתמש. בתרחישים האלה, המשתמשים יראו שוב את מסך ההסכמה ל-OAuth ויתבקשו להביע הסכמה להרשאה.

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

הסרת גישת OAuth ל-Looker (Google Cloud Core)‎

חשוב: מומלץ להסיר את הגישה למופע של Looker (Google Cloud core) באמצעות IAM ולא מתוך המופע.

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

שימוש ב-OAuth כשיטת אימות גיבוי

‫OAuth היא שיטת האימות לגיבוי כש-SAML או OIDC מוגדרות כשיטת האימות העיקרית.

כדי להגדיר OAuth כשיטת הגיבוי, צריך להעניק לכל משתמש ב-Looker (ליבת Google Cloud) את תפקיד ה-IAM המתאים כדי להיכנס למופע.

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

1. בדף הכניסה, בוחרים באפשרות אימות באמצעות Google.
2. מופיעה תיבת דו-שיח לאישור האימות של Google. לוחצים על אישור בתיבת הדו-שיח.

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

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

• קישור Looker (Google Cloud Core)‎ למסד הנתונים
• הגדרת מופע של Looker (Google Cloud Core)‎
• הגדרות אדמין ב-Looker (Google Cloud Core)‎
• ניהול מופע של Looker (Google Cloud Core)‎ ממסוף Google Cloud