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

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

יצירת רשימת ACL

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

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

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

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

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

ירושה של ACL

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

הגדרת ירושה

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

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

באיור 1 מוצג איך משתמשים ב-method‏ 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 של פריט ההורה מכחישה למשתמש גישה כקורא, עדיין תהיה לו גישה אם יש לו גישה לפריט הצאצא כקורא. לעומת זאת, גם אם רשימת הרשאות הגישה של פריט ההורה מעניקה למשתמש גישה, למשתמש לא תהיה גישה אם הרשאת הקריאה שלו בפריט הצאצא נדחתה.

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

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

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

מחיקת פריטים ובלימה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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