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

כדי לוודא שרק משתמשים שיש להם גישה לפריט יכולים לראות אותו בתוצאות החיפוש, צריך לאנדקס פריטים עם רשימות בקרת הגישה (ACL) שלהם ממאגר המידע הארגוני. צריך ליצור מודל של רשימות ה-ACL של המאגר ולכלול אותן כשמבצעים אינדוקס של פריטים. ערכת Content Connector SDK מספקת שיטות ליצירת מודלים של רשימות 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. השיטה setInheritFrom.

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

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

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

  • משתמש 1 הוא חשבון משתמש מורשה עקיף של פריט B בלי שצוין במפורש; הגישה עוברת בירושה מפריט A.
  • משתמש 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 לא יכול לגשת לפריט ג'.
שרטוט של קשרים בין פריטים
איור 2. השיטה setInheritFrom בשימוש.

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

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

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

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

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

שרטוט של קשרים בין פריטים
איור 3. מחיקת פריט והרשאות גישה (ACL) שמועברות בירושה.

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

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

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

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