CIAM 102: التفويض والتحكم في الوصول القائم على الأدوار

الخلفية#

في المقال السابق، قدمنا مفهوم المصادقة (AuthN) والتفويض (AuthZ)، إلى جانب بعض المصطلحات المعجزة: الهوية، المنظمة، المستأجر، إلخ.

التنظيم والمستأجر رائعان لتجميع الهويات، ولكن يؤديان إلى ديمقراطية مطلقة: يمكن للجميع فعل أي شيء في هذا النظام. بينما لا تزال المدينة الفاضلة لغزًا، دعونا نلقي نظرة على حوكمة الوصول: التفويض (AuthZ).

لماذا نحتاج إلى التفويض؟#

البرنامج Notion مثال رائع. لكل صفحة تملكها، يمكنك اختيار إبقائها خاصة، متاحة لك فقط، أو مشاركتها مع الأصدقاء، أو حتى العامة.

أو، بالنسبة لمتجر كتب على الإنترنت، تريد أن يتاح للجميع عرض جميع الكتب، ولكن أن يتمكن العملاء فقط من عرض طلباتهم الخاصة، والبائعون من إدارة الكتب في متاجرهم فقط.

AuthZ و AuthN هما مكونات أساسية لنموذج أعمال معقد. غالبًا ما يسيران جنبًا إلى جنب؛ AuthZ يتحقق من وصول المستخدم، بينما AuthN يصادق على الهويات. كلاهما ضروري لنظام آمن.

نموذج التفويض الأساسي#

إليك واحد من أكثر نماذج AuthZ شيوعًا: إذا كان الهوية ينفذ الفعل على المورد، فحينئذٍ قبول أو رفض.

في مثال Notion، النموذج هو الشخص ينفذ عرض على الصفحة.

إذا كانت الصفحة خاصة:

• ستتلقى قبول عند تنفيذ عرض على صفحتك.
• يجب أن يتلقى الجميع رفض عند تنفيذ عرض على صفحتك.

بناءً على التوافق، طورت الصناعة تقنيات تفويض متنوعة، مثل التحكم في الوصول القائم على الأدوار (RBAC)، والتحكم في الوصول القائم على السمات (ABAC). اليوم، سنركز على نموذج NIST RBAC المستوى 1: RBAC المسطح.

التحكم في الوصول القائم على الأدوار#

لنوسع مثال متجر الكتب. لنفترض أننا لدينا العديد من العملاء، ولكن بائع واحد فقط:

• يمكن للعملاء عرض وطلب الكتب، وكذلك عرض طلباتهم الخاصة.
• يمكن للبائع عرض، إنشاء، وحذف الكتب، وإدارة طلبات العملاء.

تعريف الموارد#

في Logto، عادةً ما يمثل المورد (أي: مورد API) مجموعة من الكيانات أو العناصر، لأنه مطلوب استخدام عنوان URL صالح كمؤشر. لذا نعرف موردين:

• الكتب: https://api.bookstore.io/books
• الطلبات: https://api.bookstore.io/orders

ومن مزايا فرض تنسيق URL يمكن أن يرتبط بعنوان حقيقي لخدمة API الخاصة بك، مما يحسن من سهولة القراءة والاعتراف بها عند التكامل مع مكونات أخرى في النظام.

تعريف الأذونات#

نظرًا لأننا قدمنا مفهوم المورد، في Logto، نفرض أيضًا أن الأذونات يجب أن تنتمي إلى مورد، في المقابل، يمكن أن يحتوي الموارد على أذونات.

لنضف بعض الأذونات إلى الموارد:

• الكتب: قراءة, إنشاء, حذف
• الطلبات: قراءة, قراءة:النفس, إنشاء:النفس, حذف

على الرغم من عدم وجود اشتراط للاسم الخاص بإذن، لدينا العرف التالي:

بينما يجب على <فعل> وصف الإذن، يمكن تجاهل :<هدف> لوصف هدف عام، أي لجميع الكيانات أو العناصر في المورد. على سبيل المثال:

• الإذن قراءة في مورد الكتب يعني الفعل لقراءة الكتب العشوائية.
• الإذن إنشاء:النفس في مورد الطلبات يعني الفعل لإنشاء طلبات تنتمي إلى المستخدم الحالي.

تعريف الأدوار#

باختصار، الدور هو مجموعة من الأذونات. لنقم بإنشاء دورين عميل و بائع ونخصص الأذونات لهم كما يلي:

قد تلاحظ أن تعيين الإذن للدور هو علاقة عديدة لعديد.

تخصيص الأدوار للمستخدمين#

تمامًا مثل تعيين الدور للإذن، فإن تعيين المستخدم للدور هو أيضًا علاقة عديدة لعديد. لذلك، يمكنك تخصيص أدوار متعددة لمستخدم واحد، ويمكن تخصيص دور واحد لعدة مستخدمين.

ربط النقاط#

إليك رسم بياني كامل للعلاقات لنموذج RBAC المستوى 1 في Logto:

في نموذج RBAC، تكون الأذونات دائمًا "إيجابية"، مما يعني أن حكم التفويض بسيط: إذا كان لدى المستخدم الإذن، فاقبل؛ والا، ارفض.

لنقل أن أليس لديها دور بائع، بوب وكارول لديهما دور عميل. سنصف الأفعال بلغة طبيعية أولاً، ونحولها إلى تنسيق التفويض القياسي: الهوية ينفذ الفعل على المورد، وأخيرًا نعطي النتيجة.

• تريد أليس إضافة كتاب جديد للبيع:
  • المستخدم أليس ينفذ إنشاء على مورد الكتب (https://api.bookstore.io/books).
  • نظرًا لأنه تم تخصيص الإذن إنشاء للكتب لأليس وفقًا لدورها بائع، النتيجة هي ✅ قبول.
• تريد أليس عرض جميع الطلبات لمعرفة ما إذا كانت المبيعات تفي بتوقعاتها:
  • المستخدم أليس ينفذ قراءة على مورد الطلبات (https://api.bookstore.io/orders).
  • نظرًا لأنه تم تخصيص الإذن قراءة للطلبات لأليس وفقًا لدورها بائع، النتيجة هي ✅ قبول.
• يريد بوب تصفح قائمة الكتب لمعرفة ما إذا كانت هناك كتب يرغب في شرائها.
  • المستخدم بوب ينفذ قراءة على مورد الكتب (https://api.bookstore.io/books).
  • نظرًا لأنه تم تخصيص الإذن قراءة للكتب لبوب وفقًا لدوره عميل، النتيجة هي ✅ قبول.
• يريد بوب عرض طلب كارول.
  • نظرًا لأنه طلب شخص آخر، فإن الإذن قراءة:النفس للطلبات لا يعمل هنا.
  • المستخدم بوب ينفذ قراءة على مورد الطلبات (https://api.bookstore.io/orders).
  • نظرًا لعدم امتلاك بوب إذن قراءة للطلبات، النتيجة هي ❌ رفض.

مستويات RBAC الأخرى#

هناك أربع مستويات في نموذج NIST RBAC:

• RBAC المسطح
• RBAC الهرمي
• RBAC المقيد
• RBAC المتناظر

راجع الورقة للحصول على التفاصيل إذا كنت مهتمًا.

يمتلك Logto الآن تطبيق المستوى 1 وسيتقدم إلى مستويات أعلى بناءً على ملاحظات المجتمع. لا تتردد في إخبارنا إذا كان مستوى أعلى يناسب احتياجك!

في الممارسة العملية#

بجانب النظرية، لا يزال لدينا أعمال تقنية ثقيلة لنكمل لجعل النموذج يعمل بالشكل المتوقع:

• تطوير العميل والخادم الخاص بالمصادقة
• تصميم قاعدة بيانات لـ RBAC
• التحقق عبر الخدمات المختلفة
• الأمان والامتثال للمعايير المفتوحة
• إدارة وتعيين الأدوار، الأذونات، والموارد

لا داعي للذعر. لقد أخذنا ذلك في الاعتبار وأضفنا دعمًا جاهزًا لتغطية كل ما سبق. تحقق من 🔐 وصفة RBAC لمعرفة كيفية استخدام RBAC في Logto.

ملاحظات ختامية#

RBAC هو نموذج إدارة الوصول قوي لمعظم الحالات، ولكن ليس هناك رصاصة سحرية. لا يزال لدينا بعض الأسئلة:

• هل أحتاج إلى مستويات عالية من RBAC؟
• كيف يقارن RBAC مع نماذج التفويض الأخرى؟
• كيفية تعريف نموذج التفويض بين منظمات مختلفة؟