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

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

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