רשימות ACL של מפות

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

הערה: Content Connector SDK תומך ברשימות ACL של דומיין יחיד, אבל לא ברשימות ACL של דומיינים שונים. אי אפשר להעניק גישה לקבוצות ולמשתמשים מחוץ לארגון. לרשימות ACL שמפנות למשתמשים או לקבוצות מחוץ לארגון אין השפעה.

יצירת ACL

יצירת רשימת ACL היא תהליך דו-שלבי:

1. יצירת Principal באמצעות שיטות סטטיות במחלקה ACL.
2. שימוש במחלקה Acl.Builder כדי ליצור את ה-ACL באמצעות חשבון המשתמש.

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

יצירת חשבון משתמש באמצעות מזהה חיצוני

כדי להשתמש ב-Google Cloud Search, צריך שמשתמשים וקבוצות ישתלבו עם כתובות האימייל של Google. כשמוסיפים פריטים ממאגר לאינדקס, יכול להיות שלמחברי התוכן אין את כתובות האימייל האלה. עם זאת, ה-SDK של מחבר התוכן מאפשר להשתמש בכל מזהה חיצוני (מזהה שמעניק למשתמש או לקבוצה גישה לפריטי מאגר), במקום בכתובת אימייל, כדי להוסיף פריט לאינדקס. משתמשים ב-method getUserPrincipal() או ב-method getGroupPrincpal() כדי ליצור חשבונות משתמשים עם מזהים חיצוניים. במחלקה ACL קיימות כמה שיטות סטטיות נוספות שמשמשות לבניית אובייקטים של Principal.

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

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

ירושה של ACL

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

הגדרת ירושה

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

פריט יכול לרשת גם חשבונות משתמשים מורשים עקיפים וחשבונות משתמשים שנדחו באופן עקיף באמצעות method setInheritFrom(). חשבון משתמש מותר באופן עקיף הוא משתמש שיש לו גישה עקיפה לפריט ספציפי, דרך ירושה של ACL. חשבון משתמש שנדחה באופן עקיף הוא משתמש שמקבל גישה לפריט ספציפי באמצעות ירושה של ACL.

הערה: אם מגדירים ירושה באמצעות method setInheritFrom(), צריך להגדיר את סוג הירושה באמצעות method setInheritanceType(). למידע נוסף על סוגי ירושה, קראו את המאמר הגדרת סוג ירושה.

באיור 1 מוצג האופן שבו השיטה setInheritFrom() משמשת לירושה של חשבונות משתמשים מורשים ועקיפים שנדחו.

איור 1. השיטה setInheritFrom().

בקרות הגישה הבאות מיוצגות באיור 1:

• משתמש 1 הוא חשבון משתמש מורשה ישיר של פריט א'.
• משתמש 2 הוא חשבון משתמש מורשה ישיר של פריט ב'.
• פריט ב' יורש את ה-ACL של פריט א'.

כללי הגישה, שמבוססים על בקרות הגישה, הם:

• אין צורך לציין את משתמש 1 באופן מפורש כחשבון משתמש של פריט ב', כדי שהוא יהיה חשבון משתמש מורשה בעקיף של פריט ב'. הגישה עוברת בירושה כי משתמש 1 רשום כחשבון משתמש מורשה ישיר של פריט א', ופריט ב' יורש את רשימת ה-ACL שלו מפריט א'.
• משתמש 2 לא יכול להיות חשבון משתמש עקיף שאושר לפריט א'.

הגדרת סוג הורשה

אם מגדירים ירושה באמצעות method setInheritFrom(), צריך להגדיר את סוג הירושה באמצעות method setInheritanceType(). סוג הירושה קובע את האופן שבו רשימת ה-ACL של צאצא תשתלב עם ה-ACL של ההורה. הקוד Acl.InheritanceType מטמיע שלושה סוגי ירושה:

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

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

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

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

לדוגמה, אם לילד או לילדה יש סוג ירושה מסוג CHILD_OVERRIDE ולמשתמש יש גישה לילד או לילדה, Drive לא צריך להעריך את ההורה. עם זאת, אם לילד או לילדה יש PARENT_OVERRIDE או BOTH_PERMIT, המערכת של Drive תמשיך להעריך את הירושה בהמשך השרשרת.

מכללה ומחיקה של פריטים

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

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

בקרות הגישה הבאות מיוצגות באיור 2:

• משתמש 1 הוא חשבון משתמש מורשה ישיר של פריט א'.
• משתמש 2 הוא חשבון משתמש מורשה ישיר של פריט ב'.
• משתמש 3 הוא חשבון משתמש מורשה ישיר של פריט ג'.
• פריט ג' יורש את ה-ACL של פריט א'.
• פריט ב' מציין את פריט א' כמאגר שלו.
• פריט ג' מציין את פריט ב' כמאגר שלו.

כללי הגישה, שמבוססים על בקרות הגישה, הם:

• הגישה העקיפה מבוססת על method setInheritFrom(). לכן, משתמש 1 יכול לגשת לפריט ג' כי פריט ג' יורש את רשימת ה-ACL של פריט א'.
• גישה עקיפה לא מגיעה מפריט ג' שנכלל בפריט ב'. לכן, למשתמש 2 אין גישה לפריט ג'.

איור 2. השיטה setInheritFrom() בשימוש.

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

אחרי שמוחקים פריט בהצלחה:

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

אם במשאב יש פריט שנמחק בשיטה setInheritFrom(), אבל לא קיימת בו קבוצת קונטיינרים עם שימוש ב-setContainer() או שהיררכיית המאגר לא מכילה פריטים שנמחקו, הפריט והנתונים שלו יישארו במקור הנתונים של Google. האחריות למחיקת הפריט היא שלך.

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

איור 3. מחיקת פריט וירושה של ACL.

בקרות הגישה הבאות מיוצגות באיור 3:

• משתמש 1 הוא חשבון משתמש מורשה ישיר של פריט א'.
• משתמש 2 הוא חשבון משתמש מותר ישיר של פריט ד.
• פריט ד' ופריט ה' יורשים את רשימת ה-ACL של פריט א'.
• פריט ד' מציין את פריט א' כמאגר שלו.
• פריטים א' ו-ה' הם פריטים ברמה הבסיסית (root), כי אין להם פריט מאגר.

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

• כל הצאצאים של ההפניה setInheritFrom() מאבדים את הגישה לכל המשתמשים.
• אין משתמשים יכולים לגשת לפריט א'.
• פריט ד' נמחק באופן לא מפורש. אין משתמשים יכולים לגשת לפריט D.
• פריט ה' לא נמחק, כי המחיקה עוברת רק דרך הפניות לקונטיינרים.
• לא ניתן לגשת לפריט ה' והמשתמשים לא יכולים לחפש את פריט ה.