الوصول القائم على الدور إلى الأساليب

Question

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

يمكنني الكتابة في كل طريقة:

if(User.IsInRole ...) {
} else {
return ... throw ... whatever
}

كنت أفكر في أتمتة هذه العملية على سبيل المثال عن طريق إضافة سمات إلى هذه الأساليب أو ربما أي حل آخر؟

Answer 1

ألقِ نظرة على مكتبات "البرمجة الموجهة الجانب" (AOP) - والإجابات على هذا السؤال stackoverflow. يمكنك استخدام AOP لإضافة رمز فحص الدور تلقائيًا.

Answer 2

طالما أنك تستخدم مديري المدارس هناك بالفعل ...

[PrincipalPermission(SecurityAction.Demand, Role = "A role available on your principal")]
public void Foo()
{
  // Will throw an exception if the principal does not have the required role
  // Otherwise the method will execute normally
}

Answer 3

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

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

على سبيل المثال ، لنفترض أنك تكتب تطبيق تقويم مع خلفية SQL. هنالك ال SQLTransaction الكائن ، الذي لا يفوق المعاملة (حسب أعلاه) ولكن لا يزال لديه كل الحقوق لجميع الجداول التي يستخدمها التطبيق. هذه الكثير من القوة التي لا تريد أن تتجول فيها إلى مستخدمي واجهة برمجة التطبيقات (بشكل صريح أو عن طريق الخطأ ، فكر في حقن SQL). بدلاً من ذلك User الكائنات التي تصمم سلطة الكتابة فقط إلى صف هذا المستخدم في جدول المستخدمين ؛ أبضا User يمكن إنشاء ، قراءة ، تحديث ، حذف Appointment الكائنات ، والتي تمثل بالمثل سلطة محدودة في جدول المواعيد.

للحفاظ على RBAC في جميع أنحاء API ، يجب عليك التأكد من أن الانتظار التالي:

1. يمكن للمستخدمين الشرعيين فقط الوصول إلى User كائن يمثلهم. هذا هو المكان الذي تقوم فيه بتوصيل نظام المصادقة إلى User البناء؛
2. ال User الكائنات لا سلطة تسرب, ، أي عليك مراجعة واجهة برمجة التطبيقات الخاصة بك للتأكد من أنه من خلال ممارسة استدعاء طريقة User (أو أي كائن ذي صلة يعودون ، بشكل متكرر) لا يمكنك قراءة أو تغيير أي موارد لا تنتمي إلى هذا المستخدم. هذا هو المكان الذي يمكنك تطبيقه الوجه نمط - على سبيل المثال User.GetAppointments() يعود حقيقي Appointment مثيلات المواعيد التي أنشأها هذا المستخدم ، ولكن الأغلفة للقراءة فقط لتلك التي أنشأها شخص آخر.