برای اطمینان از اینکه فقط کاربرانی که به یک آیتم دسترسی دارند میتوانند آن را در نتایج جستجو ببینند، آیتمها را با لیستهای کنترل دسترسی (ACL) خود از مخزن سازمانی فهرستبندی کنید. شما باید ACLهای مخزن را مدلسازی کرده و هنگام فهرستبندی آیتمها، آنها را لحاظ کنید. کیت توسعه نرمافزار رابط محتوا (Content Connector SDK) روشهایی را برای مدلسازی ACLهای اکثر مخازن ارائه میدهد.
ایجاد یک ACL
ایجاد ACL یک فرآیند دو مرحلهای است:
- با استفاده از متدهای استاتیک در کلاس ACL، یک
Principalایجاد کنید. - از کلاس
Acl.Builderبرای ساخت ACL با استفاده از principal استفاده کنید.
این سند مفاهیمی را برای مدلسازی و ایجاد ACLها، مانند وراثت و مهار، پوشش میدهد.
ایجاد یک مدیر با استفاده از یک شناسه خارجی
جستجوی ابری گوگل از کاربران و گروهها میخواهد که به آدرسهای ایمیل گوگل دسترسی داشته باشند. هنگام ایندکس کردن آیتمهای مخزن، رابطهای محتوا ممکن است این آدرسهای ایمیل را نداشته باشند. با این حال، SDK رابط محتوا به شما امکان میدهد از یک شناسه خارجی (شناسهای که به کاربر یا گروه اجازه دسترسی به آیتمهای مخزن را میدهد) به جای آدرس ایمیل برای ایندکس کردن یک آیتم استفاده کنید. از متد getUserPrincipal یا متد getGroupPrincipal برای ایجاد principalهایی حاوی شناسههای خارجی استفاده کنید. کلاس ACL شامل چندین متد استاتیک دیگر برای ساخت اشیاء Principal است.
پس از تغییر نگاشت هویت یک آیتم، باید آیتمها را دوباره فهرستبندی کنید تا هویت جدید اعمال شود. برای اطلاعات بیشتر، به تغییر نگاشت هویتها مراجعه کنید.
وراثت ACL
وراثت ACL به مجوزدهی برای یک آیتم و کاربر خاص بر اساس ACLهای ترکیبی آیتم و زنجیره وراثت آن اشاره دارد. قوانین مربوط به تصمیمگیری در مورد مجوزدهی به مخزن و ویژگیهای آیتم بستگی دارد.
تنظیم وراثت
هر آیتم میتواند دارای مدیران اصلی با دسترسی مستقیم (direct allowed principals) و مدیران اصلی با دسترسی مستقیم (direct denied principals) باشد که با استفاده از متدهای setReaders و setDeniedReaders مشخص میشوند. مدیر اصلی با دسترسی مستقیم، کاربری است که در یک ACL با دسترسی مستقیم به یک آیتم شناسایی شده است. مدیر اصلی با دسترسی مستقیم، کاربری است که در یک ACL به عنوان کاربری که به یک آیتم دسترسی ندارد، شناسایی شده است.
یک آیتم همچنین میتواند با استفاده از متد setInheritFrom از principalهای غیرمستقیم مجاز و از principalهای غیرمستقیم غیرمجاز ارث ببرد. یک principal غیرمستقیم مجاز، از طریق ارثبری ACL به یک آیتم دسترسی غیرمستقیم دارد. یک principal غیرمستقیم غیرمجاز، از طریق ارثبری دسترسی غیرمجاز دارد.
شکل ۱ نحوه استفاده از متد setInheritFrom برای ارثبری از Principals را نشان میدهد.
setInheritFrom .شکل ۱ این کنترلهای دسترسی را نشان میدهد:
- کاربر ۱، یک مدیر مجاز مستقیم برای مورد A است.
- کاربر ۲ یک مدیر مجاز مستقیم برای مورد B است.
- مورد B، ACL مورد A را به ارث میبرد.
بر اساس این کنترلها، قوانین دسترسی عبارتند از:
- کاربر ۱ بدون اینکه صریحاً مشخص شود، یک کاربر اصلیِ مجاز غیرمستقیم برای مورد B است؛ این دسترسی از مورد A به ارث رسیده است.
- کاربر ۲ یک عامل اصلی مجاز غیرمستقیم برای مورد الف نیست.
نوع وراثت را تنظیم کنید
اگر وراثت را با استفاده از متد 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 خود را از یک پوشه دیگر به ارث ببرد. حذف یک پوشه، مواردی را که ACL آن را به ارث بردهاند حذف نمیکند، مگر اینکه آن موارد نیز در سلسله مراتب محدودیت آن باشند.
شکل ۲ این کنترلهای دسترسی را نشان میدهد:
- کاربر ۱، یک مدیر مجاز مستقیم برای مورد A است.
- کاربر ۲ یک مدیر مجاز مستقیم برای مورد B است.
- کاربر ۳ یک مدیر مجاز مستقیم برای مورد C است.
- مورد C، ACL مورد A را به ارث میبرد.
- کالای ب، کالای الف را به عنوان ظرف خود نامگذاری میکند.
- کالای C، کالای B را به عنوان ظرف خود نامگذاری میکند.
بر اساس این کنترلها، قوانین دسترسی عبارتند از:
- دسترسی غیرمستقیم از متد
setInheritFromحاصل میشود. کاربر ۱ میتواند به آیتم C دسترسی داشته باشد زیرا از آیتم A ارثبری کرده است. - دسترسی غیرمستقیم از طریق محدودسازی (containment) حاصل نمیشود. کاربر ۲ نمیتواند به مورد C دسترسی پیدا کند.
setInheritFrom در حال استفاده.جداسازی وراثت ACL از مهاربندی به شما امکان میدهد ساختارهای زیادی را مدلسازی کنید.
وقتی یک مورد را حذف میکنید:
- هر موردی که حاوی مورد حذف شده باشد، غیرقابل جستجو میشود و برای حذف برنامهریزی میشود.
- هر آیتمی که آیتم حذف شده در
setInheritFromرا مشخص کند، غیرقابل جستجو میشود.
اگر منبعی setInheritFrom برای یک آیتم حذف شده استفاده کند اما هیچ مجموعه کانتینری نداشته باشد یا سلسله مراتب آن شامل هیچ آیتم حذف شدهای نباشد، آن آیتم در منبع داده باقی میماند. شما مسئول حذف آن هستید.
شکل ۳ نمونهای از حذف برای سلسله مراتب آیتم را نشان میدهد.
شکل ۳ این کنترلهای دسترسی را نشان میدهد:
- کاربر ۱، یک مدیر مجاز مستقیم برای مورد A است.
- کاربر ۲ یک مدیر مجاز مستقیم برای مورد D است.
- موارد D و E هر دو از مورد A ارث میبرند.
- کالای D، کالای A را به عنوان ظرف خود نامگذاری میکند.
- موارد A و E موارد سطح ریشه هستند.
حذفها از طریق ارجاعات به کانتینر به صورت آبشاری انجام میشوند. وقتی مورد A را حذف میکنید:
- تمام فرزندان مرجع
setInheritFromدسترسی خود را از دست میدهند. - کاربران دیگر نمیتوانند به مورد A دسترسی داشته باشند.
- مورد D به طور ضمنی حذف شده و غیرقابل دسترسی میشود.
- مورد E حذف نمیشود اما غیرقابل دسترسی و جستجو میشود.