التخطي إلى المحتوى الرئيسي

Understanding How Casbin Matching Works in Detail

في هذا المنشور، سأشرح التصميم وتنفيذ RBAC باستخدام مكتبة Casbin. بالنسبة لمنصة SaaS التي تتعامل مع تسلسلات موارد متعددة وأدوار ترث الأذونات من المستويات الأعلى، يوفر Casbin بديلاً فعالاً يجدر النظر فيه.

مقدمة إلى RBAC

RBAC هو طريقة لتقييد الوصول إلى الموارد بناءً على الأدوار التي يحملها الأفراد. لفهم أفضل لكيفية عمل RBAC الهرمي، دعونا نلقي نظرة على نظام RBAC في Azure في القسم التالي ثم نحاول تنفيذ نظام مماثل.

فهم RBAC الهرمي في Azure

تسلسل Azure

هناك دور يسمى المالك لجميع الموارد في Azure. لنفترض إذا كان لدي دور المالك مُعين لي على مستوى الاشتراك، فهذا يعني أنني المالك لجميع مجموعات الموارد والموارد تحت ذلك الاشتراك. إذا كان لدي المالك على مستوى مجموعة الموارد، فأنا المالك لجميع الموارد تحت تلك مجموعة الموارد.

تظهر هذه الصورة أن لدي دخول المالك على مستوى الاشتراك. مالك الاشتراك

عندما أفحص IAM لمجموعة موارد تحت هذا الاشتراك، يمكنك أن ترى أنني ورثت دخول المالك من الاشتراك. مالك مجموعة الموارد

هكذا هو نظام RBAC في Azure هرمي. معظم البرمجيات المؤسسية تستخدم RBAC الهرمي بسبب الطبيعة الهرمية لمستويات الموارد. في هذا البرنامج التعليمي، سنحاول تنفيذ نظام مماثل باستخدام Casbin.

كيف يعمل Casbin؟

قبل الغوص في التنفيذ، من المهم فهم ما هو Casbin وكيف يعمل على مستوى عال. هذا الفهم ضروري لأن كل نظام للتحكم في الوصول بناءً على الدور (RBAC) قد يختلف بناءً على متطلبات محددة. بفهم عمل Casbin، يمكننا ضبط النموذج بشكل فعال.

ما هو ACL؟

ACL يعني قائمة التحكم في الوصول. هو طريقة يتم فيها تعيين المستخدمين للأفعال والأفعال للموارد.

تعريف النموذج

لنأخذ مثالاً بسيطاً على نموذج ACL.

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act
  1. request_definition هو قالب الاستعلام للنظام. على سبيل المثال، يمكن تفسير طلب alice, write, data1 على أنه "هل يمكن للموضوع Alice تنفيذ الفعل 'write' على الكائن 'data1'؟".

  2. policy_definition هو قالب التعيين للنظام. على سبيل المثال، بإنشاء سياسة alice, write, data1، أنت تعطي الإذن للموضوع Alice لتنفيذ الفعل 'write' على الكائن 'data1'.

  3. policy_effect يحدد تأثير السياسة.

  4. في قسم matchers، يتم مطابقة الطلب مع السياسة باستخدام الشروط r.sub == p.sub && r.obj == p.obj && r.act == p.act.

الآن دعونا نختبر النموذج على محرر Casbin

افتح المحرر والصق النموذج أعلاه في محرر النموذج.

الصق ما يلي في محرر السياسة:

p, alice, read, data1
p, bob, write, data2

والصق ما يلي في محرر الطلب:

alice, read, data1

النتيجة ستكون:

true

تمثيل بصري لنموذج ACL والسياسة ومطابقة الطلب

acl

ما هو RBAC؟

RBAC يعني التحكم في الوصول بناءً على الدور. في RBAC، يتم تعيين دور للمستخدم لمورد، ويمكن أن يحتوي الدور على أفعال تعسفية. ثم يتحقق الطلب إذا كان لدى المستخدم الإذن لتنفيذ الفعل على المورد.

تعريف النموذج

لنأخذ مثالاً بسيطاً على نموذج RBAC:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && g(p.act, r.act) && r.obj == p.obj
  1. role_definition هو باني علاقة الرسم البياني الذي يستخدم الرسم البياني لمقارنة كائن الطلب بكائن السياسة.

الآن دعونا نختبر النموذج على محرر Casbin

افتح المحرر والصق النموذج أعلاه في محرر النموذج.

الصق ما يلي في محرر السياسة:

p, alice, reader, data1
p, bob, owner, data2

g, reader, read
g, owner, read
g, owner, write

والتالي في محرر الطلب:

alice, read, data1
alice, write, data1
bob, write, data2
bob, read, data2
bob, write, data1

النتيجة ستكون:

true
false
true
true
false

التمثيل البصري لنموذج RBAC والسياسة وتطابق الطلب

rbac

جدول g - Role to action mapping يحتوي على رسم بياني يربط الدور بالإجراء. يمكن ترميز هذا الرسم البياني كقائمة من الحواف، كما هو موضح في السياسة وهو طريقة شائعة لتمثيل الرسم البياني:

g, reader, read
g, owner, read
g, owner, write
معلومات

p يشير إلى سياسة عادية يمكن مقارنتها باستخدام عامل التشغيل ==. g هو دالة مقارنة تعتمد على الرسم البياني. يمكنك تعريف مقارنات رسم بياني متعددة بإضافة لاحقة رقمية مثل g, g2, g3, ... وهكذا.

ما هو Hierarchical RBAC؟

في Hierarchical RBAC، هناك أكثر من نوع واحد للموارد وهناك علاقة توريث بين أنواع الموارد. على سبيل المثال، "subscription" هو نوع واحد و "resourceGroup" هو نوع آخر. يمكن لـ sub1 من نوع Subscription أن يحتوي على مجموعات موارد متعددة (rg1، rg2) من نوع ResourceGroup.

مشابهًا لتسلسل الموارد، سيكون هناك نوعان من الأدوار والإجراءات: أدوار وإجراءات الاشتراك، وأدوار وإجراءات مجموعة الموارد. هناك علاقة تعسفية بين دور الاشتراك ودور مجموعة الموارد. على سبيل المثال، ضع في اعتبارك دور الاشتراك sub-owner. يتم توريث هذا الدور بواسطة دور مجموعة الموارد rg-owner، مما يعني أنه إذا تم تعييني بدور sub-owner على الاشتراك sub1، فإنني أحصل تلقائيًا أيضًا على دور rg-owner على rg1 و rg2.

تعريف النموذج

لنأخذ مثالًا بسيطًا على نموذج Hierarchical RBAC:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && g(p.act, r.act) && g2(p.obj, r.obj)
  1. role_definition هو باني علاقة الرسم البياني الذي يستخدم رسمًا بيانيًا لمقارنة كائن الطلب بكائن السياسة.

الآن دعونا نختبر النموذج على محرر Casbin

افتح المحرر والصق النموذج أعلاه في محرر النموذج.

الصق التالي في محرر السياسة:

p, alice, sub-reader, sub1
p, bob, rg-owner, rg2

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

والصق التالي في محرر الطلب:

alice, rg-read, rg1

النتيجة ستكون:

true

التمثيل البصري لنموذج RBAC والسياسة وتطابق الطلب

hrbac

جدول g - Role to (Action, Role) Mapping يحتوي على رسم بياني يربط الدور بالإجراء، تعيين الدور. يمكن ترميز هذا الرسم البياني كقائمة من الحواف، كما هو موضح في السياسة، وهو طريقة شائعة لتمثيل الرسم البياني:

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

جدول g2 - Sub to RG Mapping يحتوي على رسم بياني يربط الاشتراك بمجموعة الموارد:

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

التمثيل البصري لتطابق الموضوع

hrbac-sub-match

التمثيل البصري لتطابق الإجراء

hrbac-act-match

التمثيل البصري لتطابق الكائن

hrbac-obj-match

معلومات

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

خاتمة

في هذا البرنامج التعليمي، تعلمنا كيف تعمل نماذج التفويض المختلفة وكيف يمكن نمذجتها باستخدام Casbin. في الجزء الثاني من هذا البرنامج التعليمي، سنقوم بتنفيذ ذلك في تطبيق تجريبي لـ Spring Boot وتأمين واجهات برمجة التطبيقات باستخدام Casbin.