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

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

יצירת רשימת ACL

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

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

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

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

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

ירושה של ACL

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

הגדרת ירושה

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

• PARENT_OVERRIDE – מגדירים את סוג הירושה ל-PARENT_OVERRIDE כדי לאלץ את רשימת ה-ACL של הפריט ההורה לקבל עדיפות על פני רשימת ה-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 ואף משתמש לא יכול לחפש אותו.