نقشه ACL ها

برای اطمینان از اینکه فقط کاربرانی که به یک مورد دسترسی دارند می‌توانند آن مورد را در یک نتیجه جستجو ببینند، باید موارد را با فهرست‌های کنترل دسترسی (ACL) از مخزن سازمانی فهرست‌بندی کنید. شما باید ACL های مخزن خود را مدل کنید و هنگام نمایه سازی آیتم ها در مخزن، آن ACL ها را لحاظ کنید. Content Connector SDK مجموعه ای غنی از روش های ACL را ارائه می دهد که به اندازه کافی قدرتمند هستند تا ACL های اکثر مخازن را مدل کنند.

توجه: Content Connector SDK از ACL های تک دامنه ای پشتیبانی می کند، اما از ACL های بین دامنه ای پشتیبانی نمی کند. شما نمی توانید به کاربران و گروه هایی که خارج از سازمان شما هستند اجازه دسترسی بدهید. هر گونه ACL که به کاربران یا گروه های خارج از سازمان شما ارجاع می دهد تأثیری ندارد.

یک ACL ایجاد کنید

ایجاد ACL یک فرآیند دو مرحله ای است:

1. یک Principal با استفاده از روش های static در کلاس ACL ایجاد کنید.
2. از کلاس Acl.Builder برای ساخت ACL با استفاده از اصل استفاده کنید.

بقیه این سند برخی از مفاهیمی را پوشش می‌دهد که برای مدل‌سازی و ایجاد ACL باید بدانید، مانند وراثت و مهار.

با استفاده از یک شناسه خارجی یک اصلی ایجاد کنید

Google Cloud Search از کاربران و گروه‌ها می‌خواهد که آدرس ایمیل Google را حل کنند. هنگام نمایه سازی موارد مخزن، رابط های محتوا ممکن است این آدرس های ایمیل را نداشته باشند. با این حال، Content Connector SDK به شما این امکان را می‌دهد که از هر شناسه خارجی (شناسه‌ای که به کاربر یا گروه اجازه دسترسی به موارد مخزن را می‌دهد)، به جای آدرس ایمیل، برای فهرست کردن یک مورد استفاده کنید. از متد getUserPrincipal() یا متد getGroupPrincpal() برای ایجاد اصولی حاوی شناسه های خارجی استفاده کنید. چندین روش استاتیک دیگر در کلاس ACL برای ساخت اشیاء Principal وجود دارد.

توجه: کاربران تا زمانی که شناسه خارجی آنها با حساب Google آنها همگام سازی نشود، موارد را در نتایج جستجو نمی بینند. همگام‌سازی این شناسه‌های کاربر خارجی یا گروه با آدرس ایمیل Google می‌تواند با استفاده از یک رابط هویت انجام شود. برای اطلاعات بیشتر در مورد رابط‌های هویت، به ایجاد رابط هویت مراجعه کنید.

هشدار: پس از نگاشت مجدد هویت یک مورد به هویت دیگر، باید موارد را مجدداً فهرست کنید تا هویت جدید ثابت شود. برای اطلاعات بیشتر، به Remapping identities مراجعه کنید.

وراثت ACL

وراثت ACL به مجوز، برای یک آیتم خاص و یک کاربر خاص، بر اساس نتیجه ترکیبی از ACLهای مورد و ACLهای زنجیره ارثی آن اشاره دارد. قوانین مورد استفاده برای تصمیم گیری مجوز به مخزن و ویژگی های مورد بستگی دارد.

وراثت را تنظیم کنید

هر آیتم می تواند دارای اصول مجاز مستقیم و اصول رد شده مستقیم باشد که با استفاده از متدهای setReaders() و setDeniedReaders() مشخص شده اند. یک اصل مجاز مستقیم، کاربری است که در ACL شناسایی می شود و به آنها دسترسی مستقیم به یک آیتم خاص می دهد. یک اصلی رد شده مستقیم، کاربری است که در ACL شناسایی شده است که به یک آیتم خاص دسترسی ندارد.

یک آیتم ممکن است با استفاده از متد setInheritFrom() اصول غیرمستقیم مجاز و اصول غیرمستقیم رد شده را به ارث ببرد. یک اصل مجاز غیر مستقیم، کاربری است که از طریق وراثت ACL، دسترسی غیرمستقیم به یک آیتم خاص دارد. یک اصل غیرمستقیم رد شده، کاربری است که از طریق وراثت ACL، از دسترسی به یک آیتم خاص محروم است.

توجه: اگر وراثت را با استفاده از متد setInheritFrom() تنظیم کنید، باید نوع وراثت را با استفاده از متد setInheritanceType() تنظیم کنید. برای اطلاعات در مورد انواع وراثت، به تنظیم نوع وراثت مراجعه کنید.

شکل 1 نشان می دهد که چگونه متد setInheritFrom() برای به ارث بردن اصول غیرمستقیم مجاز و غیرمستقیم رد شده استفاده می شود.

شکل 1. متد setInheritFrom() .

این کنترل های دسترسی در شکل 1 نشان داده شده اند:

• کاربر 1 یک اصل مجاز مستقیم مورد A است.
• کاربر 2 یک اصل مجاز مستقیم مورد B است.
• مورد B ACL مورد A را به ارث می برد.

بر اساس کنترل های دسترسی، قوانین دسترسی عبارتند از:

• لازم نیست کاربر 1 به طور صریح به عنوان یک اصل مورد B مشخص شود تا یک اصل مجاز غیر مستقیم مورد B باشد. دسترسی به ارث می رسد زیرا کاربر 1 به عنوان یک اصل مجاز مستقیم مورد A فهرست شده است و مورد B ACL خود را از مورد A به ارث می برد.
• کاربر 2 یک اصل مجاز غیر مستقیم برای مورد A نیست.

تنظیم نوع وراثت

اگر وراثت را با استفاده از متد setInheritFrom() تنظیم کنید، باید نوع وراثت را با استفاده از متد setInheritanceType() تنظیم کنید. نوع ارثی تعیین می کند که چگونه ACL کودک با ACL والدینش ترکیب می شود. Acl.InheritanceType سه نوع وراثت را پیاده سازی می کند:

• BOTH_PERMIT - نوع وراثت را روی BOTH_PERMIT تنظیم کنید تا فقط زمانی به کاربر اجازه دسترسی به مورد را بدهید که هم ACL مورد فرزند و هم ACL مورد ارثی والدین به آن کاربر اجازه دسترسی به آن مورد را بدهد.

• CHILD_OVERRIDE - نوع وراثت را روی CHILD_OVERRIDE تنظیم کنید تا ACL مورد فرزند را مجبور کنید در صورت تداخل آنها بر ACL مورد اصلی ارثی اولویت داشته باشد. بنابراین، اگر ACL مورد والد دسترسی به کاربر را به عنوان خواننده رد شده رد کند، اگر کاربر به عنوان خواننده به آیتم فرزند دسترسی داشته باشد همچنان دسترسی دارد. برعکس، حتی اگر ACL مورد والد به کاربر اجازه دسترسی بدهد، اگر کاربر از خواننده کودک محروم باشد، دسترسی نخواهد داشت.

• PARENT_OVERRIDE - نوع وراثت را روی PARENT_OVERRIDE تنظیم کنید تا ACL مورد اصلی را مجبور کنید در صورت تداخل آنها بر ACL مورد اصلی اولویت داشته باشد. بنابراین، اگر ACL آیتم فرزند دسترسی به کاربر را به عنوان خواننده رد شده رد کند، اگر کاربر به عنوان خواننده به آیتم والد دسترسی داشته باشد، همچنان دسترسی دارد. برعکس، حتی اگر ACL مورد فرزند به کاربر اجازه دسترسی بدهد، اگر کاربر از خواننده مورد والد محروم باشد، دسترسی نخواهد داشت.

هنگام ارزیابی یک زنجیره ارثی ACL، ترتیب ارزیابی می تواند نتیجه تصمیم مجوز را تغییر دهد. Cloud Search ترتیب برگ به ریشه ارزیابی زنجیره های وراثت ACL را ارائه می دهد. به طور خاص، تصمیم ACL برای یک زنجیره با ارزیابی کودک با والدینش شروع می شود و می تواند تا والد اصلی پیشرفت کند.

برای مثال، اگر فرزند دارای نوع وراثت CHILD_OVERRIDE باشد و کاربر به فرزند دسترسی داشته باشد، Drive نیازی به ارزیابی والدین ندارد. با این حال، اگر فرزند PARENT_OVERRIDE یا BOTH_PERMIT داشته باشد، Drive به ارزیابی وراثت بیشتر در زنجیره ادامه می‌دهد.

محدودیت و حذف آیتم

هنگام نمایه سازی یک آیتم، می توانید با استفاده از متد setContainer() از کلاس IndexingItemBuilder ، یک آیتم را به عنوان یک ظرف برچسب گذاری کنید. رابطه ظرف/حفظه سلسله مراتب فیزیکی اقلام را ایجاد می کند و اطمینان می دهد که اقلام به درستی حذف شده اند. هنگامی که یک ظرف حذف می شود، موارد موجود نیز حذف می شوند.

روابط مهار کاملاً مستقل از قوانین وراثت ACL هستند. به عنوان مثال، یک فایل در یک سیستم فایل می تواند توسط یک پوشه به منظور حذف وجود داشته باشد، اما ACL را از یک پوشه دیگر به ارث ببرد. حذف یک پوشه، مواردی را که ACL آن را به ارث می برند، حذف نمی کند، مگر اینکه آن موارد نیز در سلسله مراتب محتوی پوشه باشند.

این کنترل های دسترسی در شکل 2 نشان داده شده اند:

• کاربر 1 یک اصل مجاز مستقیم مورد A است.
• کاربر 2 یک اصل مجاز مستقیم مورد B است.
• کاربر 3 یک اصل مجاز مستقیم مورد C است.
• مورد C ACL مورد A را به ارث می برد.
• مورد B مورد A را به عنوان ظرف خود نام می برد.
• مورد C مورد B را به عنوان ظرف خود نام می برد.

بر اساس کنترل های دسترسی، قوانین دسترسی عبارتند از:

• دسترسی غیر مستقیم از متد setInheritFrom() حاصل می شود. بنابراین، کاربر 1 می تواند به مورد C دسترسی داشته باشد زیرا مورد C ACL مورد A را به ارث می برد.
• دسترسی غیرمستقیم از مورد C که در مورد B وجود دارد حاصل نمی شود. بنابراین کاربر 2 نمی تواند به مورد C دسترسی پیدا کند.

شکل 2. متد setInheritFrom() در حال استفاده.

جداسازی وراثت ACL از سلسله مراتب مهار به شما امکان مدل سازی بسیاری از ساختارهای موجود را می دهد.

هنگامی که یک مورد با موفقیت حذف شد:

• هر موردی که حاوی یک مورد حذف شده باشد غیرقابل جستجو می شود و برای حذف از منبع داده Google برنامه ریزی شده است.
• هر آیتمی که آیتم حذف شده را با استفاده از متد setInheritFrom() مشخص کرده باشد غیرقابل جستجو می شود.

اگر منبعی دارای یک مورد حذف شده با استفاده از روش setInheritFrom() باشد، اما مجموعه کانتینری با استفاده از setContainer() نداشته باشد، یا سلسله مراتب محتوی آن حاوی موارد حذف شده نباشد، آن مورد و داده های آن در منبع داده Google باقی می مانند. شما مسئول حذف آیتم هستید.

شکل 3 نمونه ای از نحوه عملکرد حذف برای سلسله مراتب آیتم را نشان می دهد.

شکل 3. حذف یک آیتم و وراثت ACL.

این کنترل های دسترسی در شکل 3 نشان داده شده اند:

• کاربر 1 یک اصل مجاز مستقیم مورد A است.
• کاربر 2 یک اصل مجاز مستقیم مورد D است.
• مورد D و مورد E هر دو ACL مورد A را به ارث می برند.
• مورد D مورد A را به عنوان ظرف خود نام می برد.
• آیتم های A و E آیتم های سطح ریشه هستند زیرا آیتم ظرفی ندارند.

آبشار را از طریق مراجع کانتینر حذف می کند. هنگامی که مورد A حذف می شود:

• همه نوادگان مرجع setInheritFrom() دسترسی همه کاربران را از دست می دهند.
• هیچ کاربری نمی تواند به مورد A دسترسی داشته باشد.
• مورد D به طور ضمنی حذف می شود. هیچ کاربری نمی تواند به مورد D دسترسی داشته باشد.
• مورد E حذف نمی شود، زیرا حذف فقط از طریق مراجع ظرف آبشاری می شود.
• مورد E غیر قابل دسترس می شود و هیچ کاربری نمی تواند مورد E را جستجو کند.