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

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

יצירת ACL

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

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

במסמך הזה מוסברים מושגים שקשורים ליצירה של רשימות ACL, כמו ירושה והכלה.

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

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

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

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

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

הגדרת ירושה

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

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

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

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

• משתמש 1 הוא ישות ראשית מורשית ישירה של פריט א'.
• משתמש 2 הוא גורם ישיר שמורשה לגשת לפריט ב'.
• פריט ב' מקבל בירושה את ה-ACL של פריט א'.

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

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

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

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

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

ב-Cloud Search, שרשראות של ירושת ACL מוערכות מעלה לעלה. ההערכה מתחילה בילד ובהורים שלו, ויכולה להתקדם להורה הראשי.

לדוגמה, אם הילד משתמש ב-CHILD_OVERRIDE ולמשתמש יש גישה, Cloud Search לא צריך להעריך את ההורה. עם זאת, אם הצאצא משתמש ב-PARENT_OVERRIDE או ב-BOTH_PERMIT, ‏ Cloud Search ממשיך לבצע הערכה בשרשרת.

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

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

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

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

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

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

• גישה עקיפה מגיעה מהשיטה setInheritFrom. למשתמש 1 יש גישה לפריט ג' כי הוא מקבל את ההרשאות שלו מפריט א'.
• גישה עקיפה לא נובעת מהכלה. משתמש 2 לא יכול לגשת לפריט ג'.

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

כשמוחקים פריט:

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

אם משאב משתמש ב-setInheritFrom לפריט שנמחק אבל לא מוגדר לו מאגר תגים או שההיררכיה שלו לא מכילה פריטים שנמחקו, הפריט נשאר במקור הנתונים. באחריותכם למחוק אותו.

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

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

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

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

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