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

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

יצירת ACL

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

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

בהמשך המסמך נפרט כמה מושגים שצריך להכיר כדי לבנות מודלים של רשימות ACL וליצור רשימות ACL, כמו ירושה ובלימה.

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

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

ירושה של ACL

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

הגדרת הורשה

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

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

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

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

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

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

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

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

אם מגדירים ירושה באמצעות השיטה setInheritFrom(), צריך להגדיר את סוג הירושה באמצעות השיטה 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 לא יכול לגשת לפריט ג'.

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

כשפריט נמחק בהצלחה:

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

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

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

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

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

מחיקת מדורגת דרך הפניות הקונטיינר. כשפריט א' נמחק:

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