אדמינים ב-Looker יכולים לקבוע מה משתמש או קבוצת משתמשים יכולים לראות ולעשות ב-Looker על ידי הגדרת הגישה הבאה:
- גישה לתוכן, שקובעת אם משתמש או קבוצת משתמשים יכולים לצפות בתיקייה או לנהל את התיקייה. משתמש שיש לו הרשאת צפייה בתיקייה יכול לנווט לתיקייה ולראות את רשימות מרכזי הבקרה והתצוגות בתיקייה. משתמש שיש לו הרשאה לנהל תיקייה יכול לבצע פעולות על התוכן של התיקייה (העתקה, העברה, מחיקה ושינוי שם של מרכזי בקרה ו-Looks), לארגן את התיקייה עצמה (שינוי שם, העברה או מחיקה של התיקייה) ולתת למשתמשים ולקבוצות אחרים גישה לתיקייה. אדמינים ב-Looker מנהלים את הגישה לתוכן בחלונית Admin, או משתמשים בודדים מתוך התיקייה, אם יש להם הרשאה לעשות זאת.
- גישה לנתונים, שקובעת אילו נתונים מותר למשתמש לראות. הגישה לנתונים מנוהלת בעיקר באמצעות Model Sets, שמהווים חצי מתפקיד ב-Looker. התפקידים האלה מוקצים למשתמשים ולקבוצות. אפשר להגביל עוד יותר את הגישה לנתונים במודל באמצעות מסנני גישה, כדי להגביל את השורות של הנתונים שהמשתמשים יכולים לראות, כאילו הוחל מסנן אוטומטי על השאילתות שלהם. אפשר גם להגביל את הגישה לניתוחים, לצירופים, לתצוגות או לשדות ספציפיים באמצעות הרשאות גישה.
- גישה לתכונות, שקובעת אילו סוגי פעולות מותר למשתמש לבצע ב-Looker, כולל צפייה בנתונים ובתכנים שמורים, שינוי מודלים של LookML, ניהול Looker וכן הלאה. הגישה לפיצ'רים מנוהלת על ידי חבילות הרשאות, שמהוות את החלק השני של תפקיד ב-Looker. חלק מההרשאות האלה חלות על כל מופע Looker, כמו האפשרות לראות את כל התזמונים לשליחת נתונים. רוב ההרשאות חלות על קבוצות מודלים ספציפיות, כמו האפשרות לראות לוחות בקרה שהוגדרו על ידי המשתמשים על סמך המודלים האלה.
הגישה לנתונים, הגישה לפיצ'רים והגישה לתוכן של משתמשים וקבוצות משולבות כדי לקבוע מה המשתמשים יכולים לעשות ולראות ב-Looker.
משתמשים וקבוצות
ב-Looker יש משתמשים בודדים וקבוצות של משתמשים. המשתמשים מנוהלים בדף Users (משתמשים) בחלונית Admin (אדמין) של Looker, והקבוצות מנוהלות בדף Groups (קבוצות) בחלונית Admin (אדמין) של Looker.
השיטה המומלצת היא להשתמש בקבוצות כדי להימנע מהצורך להקצות אמצעי בקרה למשתמשים בנפרד, להתאים אותם ולהסיר אותם. בדרך כלל, כדי לאפשר למשתמש לבצע פעולות מסוימות, צריך לוודא שהוא שייך לקבוצה אחת או יותר. אם אף שילוב של קבוצות לא מספיק, אפשר ליצור קבוצה עם משתמש אחד בלבד, ואז להרחיב את הקבוצה הזו ליותר אנשים בעתיד. במקרה של מסנני גישה, כדאי להשתמש במאפייני משתמש, כי אפשר להקצות מאפייני משתמש לקבוצות.
שליטה בגישת המשתמשים לתוכן
תיקיות ב-Looker מאפשרות לארגן קבוצות של לוחות בקרה ו-Looks. הן יכולות להכיל גם תיקיות אחרות, וכך ליצור היררכיה מקוננת של הארגון.
תיקיות מאפשרות להגדיר רמות גישה שקובעות אילו משתמשים יכולים לערוך את התוכן בתיקייה (כמו תצוגות ומרכזי בקרה), לראות את התוכן בתיקייה ולשנות את ההגדרות:
למשתמשים צריכה להיות לפחות רמת הגישה צפייה לתיקייה כדי לראות שהתיקייה קיימת, כדי לראות את התצוגות ומרכזי הבקרה בתוכה וכדי להעתיק את התצוגות ומרכזי הבקרה בתיקייה.
משתמש צריך לקבל את רמת הגישה ניהול גישה, עריכה לתיקייה כדי לנהל את הגישה לתיקייה ולערוך את התיקייה והתוכן שלה (כולל שינוי שם של תיקיות, העברת תוכן ומחיקה של תצוגות ולוחות בקרה).
במקרים אחרים, תיקיות לא קובעות מה משתמשים יכולים לעשות בפלטפורמת Looker, או באילו נתונים הם יכולים להשתמש כדי ליצור תוכן משלהם. בקטע שליטה בגישה לתכונות ולנתונים שבדף הזה מוסבר איך לנהל את רמת הגישה הזו.
הוראות מפורטות להתאמת רמות הגישה לתיקיות עבור משתמשים שמעיינים בתוכן ב-Looker מופיעות בדף התיעוד ארגון וניהול של גישה לתוכן. אדמינים ב-Looker יכולים גם לשנות את רמות הגישה לתיקיות לכל הקבוצות והמשתמשים בדף Content Access (גישה לתוכן) ב-Looker. אפשר גם לעיין בדף התיעוד תכנון והגדרה של מערכת רמות גישה כדי לקבל מידע על תכנון רמות גישה ברמת המופע.
הגישה לתוכן מנוהלת בנפרד מגישה לפיצ'רים, אבל התפקיד שמוקצה למשתמש יכול להשפיע על היכולת שלו לראות את ה-Looks ומרכזי הבקרה שמופיעים בתיקייה, לצפות ב-Look או במרכז בקרה או לנהל תיקייה. בקטע איך הגישה לתוכן והרשאות פועלות יחד בדף הזה מוסבר בפירוט איך הגישה לפיצ'רים משפיעה על הגישה לתוכן.
שליטה בגישה לתכונות ולנתונים
כדי לשלוט בגישה לתכונות ולנתונים ב-Looker, בדרך כלל יוצרים קבוצת משתמשים (זה אופציונלי, אבל מומלץ) ומקצים את הקבוצה הזו לתפקיד. תפקיד מקשר בין קבוצה של הרשאות לבין קבוצה של מודלים של LookML. המודלים עצמם מגדירים אילו שדות ונתונים זמינים.
אפשר להחיל מגבלות נתונים ספציפיות על משתמשים ספציפיים באמצעות מסנני גישה. בנוסף, אפשר להגביל את המפתחים ב-Looker לעבודה עם מודלים שמבוססים על מסדי נתונים מסוימים באמצעות פרויקטים.
אפשר גם ליצור הרשאות גישה כדי לשלוט בגישה לניתוחים, לצירופים, לתצוגות או לשדות ספציפיים. הענקת גישה מגבילה את הגישה רק למשתמשים שהוקצו להם ערכים ספציפיים של מאפייני משתמש.
| אם רוצים להשיג את זה ... | אלה השלבים הבסיסיים שצריך לבצע… |
|---|---|
| שליטה בפעולות שמשתמש יכול לבצע | יוצרים קבוצת הרשאות עם ההרשאות המתאימות, ואז מקצים קבוצה או משתמש לתפקיד עם קבוצת ההרשאות הזו. |
| קביעת השדות שהמשתמש יכול לגשת אליהם | יוצרים מודל עם השדות המתאימים, ואז מקצים קבוצה או משתמש לתפקיד עם המודל הזה. |
| שליטה בנתונים שהמשתמש יכול לגשת אליהם | יוצרים מודל עם מגבלות הנתונים המתאימות, ואז מקצים קבוצה או משתמש לתפקיד עם המודל הזה- או -שימוש במסנני גישה כדי להגביל את המשתמש לנתונים המתאימים- או -שימוש במאפייני משתמש כדי לספק פרטי כניסה שונים למסד נתונים לקבוצה או למשתמש- או -שימוש במאפייני משתמש עם הרשאות גישה כדי להגביל את הגישה לניתוחים, לצירופים, לתצוגות או לשדות ספציפיים |
| שליטה בגישה של מפתחי Looker לחיבורי מסדי נתונים | יוצרים פרויקט עם החיבורים המתאימים, משייכים את הפרויקט לקבוצת מודלים, ואז מקצים קבוצה או משתמש לתפקיד עם המודלים האלה |
הגישה לפיצ'רים יכולה להשפיע גם על הגישה לתוכן. בקטע איך גישה לתוכן והרשאות משפיעות על הגישה לתוכן בדף הזה יש פרטים נוספים על האופן שבו גישה לנתונים וגישה לתכונות משפיעות על הגישה לתוכן.
המרכיבים הבסיסיים שחשוב להבין
תפקידים
תפקיד הוא שילוב של קבוצת הרשאות אחת וקבוצת מודלים אחת. קבוצת הרשאות מורכבת מהרשאה אחת או יותר, והיא מגדירה מה התפקיד יכול לעשות. קבוצת מודלים מורכבת ממודל אחד או יותר, והיא מגדירה לאילו מודלים של LookML התפקיד חל.
אחרי שיוצרים תפקיד, אפשר להקצות לו משתמש בודד או קבוצת משתמשים. אם מוסיפים תפקידים מסוימים למשתמש ספציפי, ותפקידים אחרים לקבוצה שהמשתמש שייך אליה, המשתמש יקבל את כל התפקידים האלה.
חלק מההרשאות רלוונטיות לכל מופע Looker, ואחרות חלות רק על המודלים באותו תפקיד. מידע נוסף זמין בדף בנושא תפקידים.
פרויקטים
פרויקטים מאפשרים לכם להגביל את החיבורים למסדי נתונים שבהם יכולים להשתמש מודלים מסוימים. כך תוכלו לקבוע עם אילו מערכי נתונים מפתחי Looker יוכלו ליצור אינטראקציה כשהם יוצרים מודלים. פרויקט יכול להכיל מודל אחד או יותר, ואפשר להגדיר אותו לשימוש בחיבור אחד או יותר.
ההגבלה הזו שמוגדרת באמצעות פרויקטים חלה גם על SQL Runner ב-Looker, וכך מובטח שהמפתחים לא יוכלו לגשת לחיבורים אסורים למסדי נתונים באמצעות SQL Runner.
מאפייני המשתמשים
מאפייני משתמש מאפשרים להקצות ערכים שרירותיים לקבוצות של משתמשים או למשתמשים בודדים. לאחר מכן, המערכת משתמשת בערכים האלה כקלט לחלקים שונים ב-Looker, כדי להתאים אישית את חוויית המשתמש לכל משתמש.
אחת מהדרכים שבהן מאפייני משתמשים שולטים בגישה היא באמצעות פרמטריזציה של פרטי הכניסה למסד הנתונים, כך שיהיו ספציפיים לכל משתמש. האפשרות הזו שימושית רק אם במסד הנתונים שלכם יש כמה משתמשים עם גישה שונה לנתונים. מידע נוסף זמין בדף התיעוד בנושא מאפייני משתמש.
דרך נוספת שבה מאפייני משתמשים שולטים בגישה היא כחלק ממסנני גישה. מסנני גישה מאפשרים לכם להשתמש במאפיין משתמש אחד או יותר כמסנן נתונים. לדוגמה, יכול להיות שתרצו להקצות לכל משתמש שם חברה, ואז לוודא שכל התוכן שהוא רואה מסונן לפי השם הזה. הסבר על החלת מסנני גישה מופיע בדף התיעוד בנושא מאפייני משתמש ובדף התיעוד בנושא הפרמטר access_filter.
מאפייני משתמשים קובעים גם את הגישה. הרשאת גישה מציינת מאפיין משתמש ומגדירה ערכים מותרים במאפיין המשתמש הזה כדי להעניק גישה לניתוח נתונים, להצטרפות, לתצוגה או לשדה. לאחר מכן משתמשים בפרמטר required_access_grants ברמה של Explore, join, view או field כדי להגביל את הגישה למבני LookML האלה רק למשתמשים שיש להם את הערכים המותרים של מאפייני המשתמש. לדוגמה, אפשר להשתמש בהענקת גישה כדי להגביל את הגישה למאפיין salary רק למשתמשים שיש להם את הערך payroll במאפיין המשתמש department. במאמר access_grant מוסבר איך להגדיר הענקות גישה.
שימוש באבני הבניין
שליטה בגישה לפיצ'רים
ההרשאות קובעות את סוגי הפעילויות שמשתמש או קבוצה יכולים לבצע. כך משתמש יכול לקבל הרשאות:
- השיטה המומלצת היא לזהות קבוצה אחת או יותר של משתמשים שצריכים קבוצת הרשאות, וליצור קבוצה אם צריך. אם רוצים, אפשר לתת הרשאות למשתמשים ספציפיים.
- יוצרים קבוצת הרשאות שמכילה את ההרשאות המתאימות.
- אם חלק מההרשאות שרוצים להקצות הן ספציפיות למודל, צריך ליצור קבוצת מודלים או לזהות קבוצת מודלים קיימת.
- יוצרים תפקיד שמשלב את קבוצת ההרשאות ואת קבוצת המודלים, אם צריך.
- מקצים את התפקיד מהדף תפקידים. אחרי שהתפקיד נוצר, אפשר גם להקצות אותו למשתמש בדף משתמשים.
אפשר להקצות כמה תפקידים למשתמש או לקבוצה. במקרה כזה, למשתמשים יהיו את כל ההרשאות מכל התפקידים שהוקצו להם. לדוגמה:
- תפקיד 1 מאפשר לראות לוחות בקרה במודל 1.
- תפקיד 2 מאפשר לראות לוחות בקרה ולחקור ב-Model2.
אם מקצים את שני התפקידים לאותה קבוצת משתמשים, הם יכולים לראות את לוחות הבקרה גם ב-Model1 וגם ב-Model2, אבל הם יכולים לבצע ניתוח רק ב-Model2.
שליטה בגישת המשתמשים לשדות ב-Looker
השדות שמשתמש יכול לעבוד איתם נקבעים לפי המודלים שהמשתמש יכול לגשת אליהם. כך משתמש יכול לקבל גישה לשדה:
- יוצרים מודל LookML (או שילוב של מודלים של LookML) שמכיל רק את השדות שלמשתמש צריכה להיות גישה אליהם.
- עוברים אל ניהול > משתמשים > תפקידים.
- בדף תפקידים, יוצרים קבוצת מודלים שמכילה את המודלים האלה ואז מקצים אותה לתפקיד.
- כדי לעבוד עם קבוצות של משתמשים, מה שנחשב בדרך כלל לשיטה מומלצת, צריך ליצור קבוצה בדף Groups ב-Looker. לאחר מכן מקצים את הקבוצה לתפקידים המתאימים בדף תפקידים.
- כדי לעבוד עם משתמשים בודדים, מקצים להם תפקידים מהדף משתמשים או מהדף תפקידים.
אפשר להקצות כמה תפקידים למשתמש או לקבוצה. לאחר מכן המשתמשים יכולים לעבוד עם כל המודלים מכל התפקידים שיש להם.
חשוב לציין שהפרמטר hidden של השדות נועד ליצור חוויה נקייה יותר למשתמשים, ולא לשלוט בגישה לשדות. הפרמטר hidden מסתיר שדות מבורר השדות, אבל הוא לא ימנע ממשתמש להשתמש בשדה הזה. אם מישהו ישלח להם קישור שמשתמש בשדה הזה, הם יוכלו לראות אותו, והשדה עדיין יופיע במקומות אחרים ב-Looker.
שליטה בגישת המשתמשים לנתונים
יש כמה דרכים לשלוט בגישה של משתמשים לנתונים, בהתאם לתרחיש השימוש:
- כדי למנוע ממשתמשים לראות עמודות מסוימות של נתונים, צריך לשלוט בשדות שהם יכולים לגשת אליהם, כמו שמתואר בקטע שליטה בגישת משתמשים לשדות ב-Looker. כל עוד משתמש לא יכול לפתח ולא יכול להשתמש ב-SQL Runner, הוא מוגבל לשדות שיש לו גישה אליהם.
- כדי למנוע ממשתמשים לראות שורות מסוימות של נתונים, צריך להחיל שדות של מסנן גישה, כמו שמתואר בדף התיעוד של הפרמטר
access_filter. - כדי להגביל את הגישה ל-Explores, לצירופים, לתצוגות או לשדות ספציפיים, צריך ליצור הרשאות גישה שמגבילות את הגישה רק למשתמשים שהוקצו להם ערכי המאפיינים המותרים, כמו שמתואר בדף התיעוד של הפרמטר
access_grant. - כדי להגביל את המשתמשים ב-Looker להרצת שאילתות על משתמש ספציפי במסד נתונים, שהצוות של מסד הנתונים הגדיר להגבלת הגישה לנתונים, צריך להשתמש במאפייני משתמש. הם מאפשרים לכם להגדיר פרמטרים לחיבור למסד הנתונים, כך שקבוצת משתמשים או משתמשים בודדים יריצו את השאילתות שלהם עם פרטי כניסה ספציפיים למסד הנתונים. כדאי גם להגביל את המשתמשים לשדות המתאימים ב-Looker. אם לא, יכול להיות שמשתמש Looker ינסה להריץ שאילתה על שדה שלמשתמש מסד הנתונים שלו אין גישה אליו, והוא יקבל שגיאה.
בדומה לפרמטר השדה hidden שלא נועד לשליטה בגישה לשדה, הפרמטר hidden של כלי הניתוח לא מונע מכל המשתמשים לראות ניתוח. הפרמטר hidden מסיר את הניתוח מתפריט הניתוחים, אבל אם משתמש שמר תוכן שמפנה לניתוח מוסתר, עדיין תהיה לו גישה לנתונים של הניתוח.
אם אתם משתמשים בהטמעה חתומה, הקפידו להגדיר אמצעי בקרה לגישה לנתונים באמצעות כתובת ה-URL של ההטמעה החתומה.
שליטה בגישת מפתחים לחיבורים למסד נתונים
בניגוד למשתמשים רגילים, מפתחי Looker לא מוגבלים לחלוטין על ידי מודלים ומסנני גישה, כי הם יכולים להוסיף או לשנות מודלים של LookML. עם זאת, אדמינים עדיין יכולים להגביל את הגישה של מפתחי Looker לחיבורים מסוימים למסדי נתונים באמצעות פרויקטים. כדי לעשות את זה:
- ליצור פרויקט שמגביל מספר מסוים של מודלים למספר מסוים של חיבורים למסד נתונים. הפעולה הזו מתבצעת בדף Manage Projects (ניהול פרויקטים) ב-Looker.
- עוברים אל ניהול > משתמשים > תפקידים.
- בדף Roles (תפקידים), יוצרים קבוצת מודלים שמכילה לפחות אחד מהמודלים בפרויקט, ואז מקצים אותה לתפקיד.
- כדי לעבוד עם קבוצות של משתמשים, מה שנחשב בדרך כלל לשיטה מומלצת, צריך ליצור קבוצה בדף Groups ב-Looker. לאחר מכן מקצים את הקבוצה לתפקידים המתאימים בדף תפקידים.
- כדי לעבוד עם משתמשים בודדים, מקצים להם תפקידים מהדף משתמשים או מהדף תפקידים.
אם מפתח Looker יכול לראות מודל כלשהו שמשויך לפרויקט, הוא יוכל לראות את כל המודלים שמשויכים לפרויקט הזה. לדוגמה, זה יכול לקרות אם הקציתם למפתח Looker תפקיד עם מודל אחד בלבד, אבל המודל הזה היה חלק מפרויקט שהכיל מודלים אחרים.
איך פועלות הגישה לתוכן וההרשאות
הגישה לתוכן מנוהלת על ידי המשתמשים כשהם צופים בתיקייה, או על ידי אדמין ב-Looker בדף Content Access (גישה לתוכן) בחלונית Admin (אדמין). התפקידים שמוקצים למשתמש קובעים את הגישה שלו לתכונות ולנתונים. ההגדרה הזו משפיעה על הפעולות שהמשתמש יכול לבצע בתיקייה ועל היכולת שלו לצפות ב-Looks ובלוחות בקרה.
צפייה בנתונים במבטים ובמרכזי בקרה
כדי לראות את הנתונים של לוח בקרה או של Look, למשתמש צריכה להיות לפחות הרשאת צפייה בתיקייה שבה התוכן מאוחסן.
למשתמשים צריכות להיות הרשאות access_data ו-see_looks כדי לבחור Look ולהציג את הנתונים שלו. למשתמשים צריכות להיות הרשאות access_data ו- see_user_dashboards כדי לבחור מרכז בקרה ולהציג את הנתונים שלו.
כדי לראות את הנתונים ב-Look או במשבצת של מרכז בקרה, למשתמש צריכה להיות גישה לנתונים האלה. אם אין לכם גישה לנתונים הנדרשים:
- גם אם המשתמש יכול לראות Look שמופיע בתיקייה ולנווט אל ה-Look, השאילתה של ה-Look לא מופעלת והמשתמש לא יכול לראות את הנתונים של ה-Look.
- גם אם המשתמש יכול לראות לוח בקרה שמופיע בתיקייה ולנווט אל לוח הבקרה, כל משבצת שלמשתמש אין גישה אליה מוצגת כמשבצת ריקה. אם לוח הבקרה מכיל כרטיסים שנוצרו מכמה מודלים, המשתמש יוכל לראות את הכרטיסים שמשויכים למודלים שיש לו גישה אליהם, ובכרטיסים ממודלים אחרים תוצג שגיאה.
לדוגמה, משתמש עם גישת צפייה בתיקייה, גישה לנתונים הבסיסיים של כל התצוגות בתיקייה וההרשאות access_data ו-see_looks יכול לראות רשימה של כל התצוגות בתיקייה וגם לצפות בהן. אם למשתמש הזה אין גישה ל-LookML או למרכזי בקרה שהוגדרו על ידי המשתמש, הוא לא יראה מרכזי בקרה שעשויים להיות בתיקייה.
הצגת תיקייה ורשימות של תצוגות ומרכזי בקרה
למשתמש צריכה להיות לפחות רמת הגישה צפייה לתיקייה כדי לצפות בתיקייה ולראות את רשימת התוכן שמאוחסן בתוכה.
משתמשים שיש להם גם הרשאת see_looks לפחות יכולים לראות את השמות של ה-Looks בתיקייה. משתמשים שיש להם גם הרשאת see_user_dashboards לפחות יכולים לראות את השמות של מרכזי הבקרה בתיקייה. עם זאת, זה לא אומר שהם יכולים לראות את הנתונים של התצוגות או של מרכזי הבקרה.
לדוגמה, משתמש שיש לו הרשאת see_looks אבל אין לו הרשאת access_data יכול לראות את השמות של ה-Looks אבל לא את הנתונים שלהם.
משתמשים שיש להם הרשאה access_data, אבל אין להם הרשאה see_looks או see_user_dashboards, לא יוכלו לראות תיקיות או תוכן.
שינוי תיקייה
כדי שמשתמש יוכל לארגן תיקייה, כולל העתקה והעברה של תוכן, שינוי שם והעברה של תיקיות ופעולות דומות, צריכה להיות לו רמת הגישה ניהול גישה, עריכה לתיקייה. למשתמשים צריכה להיות גם הרשאת manage_spaces כדי ליצור, לערוך, להעביר ולמחוק תיקיות.
שימוש בתשתית הרשאות המשתמשים (LDAP, SAML ו-OpenID Connect)
אם כבר הגדרתם תשתית LDAP, SAML או OpenID, אתם יכולים להשתמש במערכת הזו כדי לנהל את הכניסות של המשתמשים. ההוראות להגדרת LDAP מפורטות בדף אימות LDAP. ההוראות להגדרת SAML מופיעות בדף התיעוד בנושא אימות SAML. הוראות להגדרת OpenID Connect מופיעות בדף התיעוד בנושא אימות OpenID Connect.
אם הגדרתם קבוצות בהטמעה של LDAP, SAML או OpenID Connect, תוכלו להשתמש גם בקבוצות האלה ב-Looker. עם זאת, יש כמה דברים שחשוב לזכור:
- כל הקבוצות שיצרתם יועברו אוטומטית אל Looker ויוצגו בדף Groups. תיצור קבוצה אחת ב-Looker לכל קבוצת LDAP, SAML או OpenID Connect, והשם של הקבוצה ב-Looker יהיה זהה לשם של הקבוצה ב-LDAP, SAML או OpenID Connect.
- תוכלו להשתמש בקבוצות האלה ב-Looker כדי להקצות רמות גישה לתיקיות ומאפייני משתמש לחברים בקבוצות.
- לא תוכלו להשתמש בקבוצות Looker כדי להגדיר תפקידים כמו בקבוצה שנוצרה באופן ידני. במקום זאת, במהלך תהליך ההגדרה תמפו את קבוצות ה-LDAP, SAML או OpenID Connect לתפקידים ב-Looker, ותוכלו לשנות את התפקידים שהוקצו רק מדפי ההגדרה של LDAP, SAML או OpenID Connect. הגישה הזו נדרשת כדי שהקבוצות שלכם ב-LDAP, ב-SAML או ב-OpenID Connect יישארו המקור היחיד של האמת. בלי ההגבלה הזו, יכול להיות שהמיפוי של קבוצה לתפקיד יסטה מהפונקציה המיועדת שלו בסכימת LDAP, SAML או OpenID Connect.
אפשר גם להשתמש ב-LDAP כדי להחיל חיבורים ספציפיים למסד נתונים על שאילתות Looker, כמו שמתואר בדף התיעוד בנושא אימות LDAP.