RBAC في الممارسة: تنفيذ تفويض آمن لتطبيقك

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

باتباع هذا الدليل، ستتعلم:

• ✨ كيفية تصميم وتنفيذ أذونات دقيقة تمنحك تحكمًا دقيقًا
• 🔒 أفضل الممارسات لتنظيم الأذونات في أدوار ذات معنى
• 👤 تقنيات للتعامل مع ملكية الموارد بفعالية
• 🚀 طرق لجعل نظام التفويض الخاص بك قابلاً للتوسع والصيانة
• 💡 تنفيذ عملي باستخدام مثال حقيقي لنظام إدارة المحتوى (CMS)

الشفرة المصدرية الكاملة لهذا الدليل متاحة على GitHub.

فهم أساسيات RBAC#

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

يمكنك معرفة المزيد عن ما هو RBAC في Auth Wiki.

ها هي المبادئ الرئيسية التي سنتبعها في تنفيذنا:

تصميم أذونات دقيقة#

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

• read:articles - عرض أي مقال في النظام
• create:articles - إنشاء مقالات جديدة
• update:articles - تعديل المقالات القائمة
• publish:articles - تغيير حالة نشر المقالات

ملكية الموارد والتحكم في الوصول#

ملكية الموارد هي مفهوم أساسي في تصميم التفويض لنظام إدارة المحتوى (CMS) لدينا. بينما يحدد RBAC ما يمكن للأدوار المختلفة القيام به، تضيف الملكية بُعدًا شخصيًا إلى التحكم في الوصول:

• الكتّاب لديهم تلقائيًا حق الوصول إلى المقالات التي أنشأوها
• هذا النموذج الطبيعي للملكية يعني أن الكتّاب يمكنهم دائمًا عرض وتحرير محتواهم الخاص
• النظام يتحقق من الأذونات الخاصة بالأدوار أو الملكية عند معالجة عمليات المقالات
• على سبيل المثال، حتى بدون إذن update:articles، يمكن للكاتب تعديل مقالاته الخاصة
• هذا التصميم يقلل من الحاجة إلى أذونات أدوار إضافية مع الحفاظ على الأمان

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

تصميم واجهة برمجة تطبيقات آمنة#

لنبدأ بتصميم الوظيفة الأساسية لنظام إدارة المحتوى (CMS) الخاص بنا من خلال نقاط النهاية لواجهة برمجة التطبيقات:

تنفيذ التحكم في الوصول لواجهة برمجة تطبيقاتك#

بالنسبة لكل نقطة نهاية، نحتاج إلى مراعاة جانبين من التحكم في الوصول:

1. ملكية الموارد - هل يملك المستخدم هذه الموارد؟
2. أذونات الأدوار - هل تسمح دور المستخدم بهذه العملية؟

إليك كيفية معالجة الوصول لكل نقطة نهاية:

إنشاء نظام أذونات يمكن أن يتوسع#

بناءً على متطلبات الوصول لواجهة برمجة التطبيقات، يمكننا تعريف هذه الأذونات:

لاحظ أن هذه الأذونات مطلوبة فقط عند الوصول إلى موارد لا تملكها. يمكن لأصحاب المقالات تلقائيًا:

• عرض مقالاتهم الخاصة (لا يحتاجون إلى read:articles)
• تحرير مقالاتهم الخاصة (لا يحتاجون إلى update:articles)
• حذف مقالاتهم الخاصة (لا يحتاجون إلى delete:articles)

بناء الأدوار الفعالة#

الآن بعد أن حددنا واجهة برمجة التطبيقات والأذونات، يمكننا إنشاء أدوار تجمع بين هذه الأذونات بشكل منطقي:

ملاحظة: الكتّاب لديهم تلقائيًا أذونات للقراءة والتحديث والحذف لمقالاتهم الخاصة، بغض النظر عن أذونات الأدوار.

كل دور مصمم بمسؤوليات محددة في الاعتبار:

• المدير: لديه التحكم الكامل في نظام إدارة المحتوى (CMS)، بما في ذلك جميع عمليات المقالات
• الناشر: يركز على مراجعة المحتوى وإدارة النشر
• الكاتب: متخصص في إنشاء المحتوى

هذا التصميم الدور يخلق فصلًا واضحًا للمسؤوليات:

• الكتّاب يركزون على إنشاء المحتوى
• الناشرون يديرون جودة المحتوى ورؤيته
• المديرون يحافظون على التحكم في النظام بشكل عام

ضبط RBAC في Logto#

قبل البدء، تحتاج إلى إنشاء حساب في Logto Cloud، أو يمكنك أيضًا استخدام نسخة Logto ذات الاستضافة الذاتية باستخدام الإصدار مفتوح المصدر من Logto.

لكن في هذا الدليل، سنستخدم Logto Cloud للبساطة.

إعداد التطبيق الخاص بك#

1. انتقل إلى "التطبيقات" في وحدة التحكم Logto لإنشاء تطبيق react جديد
   • اسم التطبيق: نظام إدارة المحتوى
   • نوع التطبيق: تطبيق ويب تقليدي
   • عناوين إعادة التوجيه: http://localhost:5173/callback

تكوين موارد واجهة برمجة التطبيقات والأذونات#

1. انتقل إلى "موارد واجهة برمجة التطبيقات" في وحدة التحكم Logto لإنشاء مورد واجهة برمجة تطبيقات جديد
   • اسم واجهة برمجة التطبيقات: واجهة برمجة التطبيقات CMS
   • معرف واجهة برمجة التطبيقات: https://api.cms.com
   • إضافة الأذونات إلى مورد واجهة برمجة التطبيقات
     • list:articles
     • read:articles
     • create:articles
     • update:articles
     • publish:articles
     • delete:articles

إنشاء الأدوار#

انتقل إلى الأدوار في وحدة التحكم Logto لإنشاء الأدوار التالية لنظام إدارة المحتوى

• المدير
  • مع جميع الأذونات
• الناشر
  • مع read:articles, list:articles, publish:articles
• الكاتب
  • مع create:articles

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

انتقل إلى قسم "إدارة المستخدمين" في وحدة التحكم Logto لإنشاء مستخدمين.

في علامة تبويب "الأدوار" في تفاصيل المستخدم، يمكنك تعيين أدوار للمستخدم.

في مثالنا، نقوم بإنشاء 3 مستخدمين بالأدوار التالية:

• أليكس: مدير
• بوب: ناشر
• تشارلي: كاتب

دمج واجهتك الأمامية مع RBAC في Logto#

الآن، قمنا بإعداد RBAC في Logto، يمكننا البدء في دمجه في الواجهة الأمامية الخاصة بنا.

ثم اتبع دليل البدء السريع في Logto لدمج Logto في التطبيق الخاص بك.

في مثالنا، نستخدم React للعرض.

بعد إعداد Logto في التطبيق الخاص بك، نحتاج إلى إضافة تكوينات RBAC ليعمل Logto.

تذكر تسجيل الخروج وتسجيل الدخول مرة أخرى لجعل هذا التغيير ساريًا إذا كنت قد سجلت الدخول بالفعل.

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

يمكنك استخدام getAccessTokenClaims من الـ useLogto للحصول على النطاقات من رمز الوصول.

ويمكنك استخدام userScopes للتحقق مما إذا كان لدى المستخدم الإذن للوصول إلى المورد.

دمج الخلفية الخاصة بك مع RBAC في Logto#

حان الوقت الآن لدمج RBAC في Logto في الخلفية الخاصة بك.

وسيط ترخيص الخادم الخلفي#

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

كما ترى، في هذا الوسيط، نتحقق مما إذا كان طلب الواجهة الأمامية يحتوي على رمز وصول صالح ونتحقق مما إذا كان الجمهور المتواجد في رمز الوصول يتطابق مع مورد واجهة برمجة التطبيقات الذي أنشأناه في وحدة التحكم Logto.

السبب في التحقق من مورد واجهة برمجة التطبيقات هو أن مورد واجهة برمجة التطبيقات لدينا يمثل فعليًا موارد خادمنا الخلفي CMS، وجميع أذونات CMS لدينا مرتبطة بمورد واجهة برمجة التطبيقات هذا.

نظرًا لأن مورد واجهة برمجة التطبيقات هذا يمثل موارد CMS في Logto، في رمز الواجهة الأمامية الخاص بنا، ندرج رمز الوصول المقابل عند إجراء طلبات واجهة برمجة التطبيقات إلى الخادم الخلفي:

الآن يمكننا استخدام وسيلة requireAuth لحماية نقاط نهاية واجهة برمجة التطبيقات الخاصة بنا.

حماية نقاط نهاية واجهة برمجة التطبيقات#

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

بالنسبة لواجهات برمجة التطبيق التي تحتاج إلى التحقق من كل من الأذونات وملكية الموارد، يمكننا استخدام وظيفة hasScopes. على سبيل المثال، في واجهة برمجة التطبيق لقائمة المقالات، يمكن للمستخدمين الذين لديهم إذن list:articles الوصول إلى جميع المقالات، بينما يمكن للكتّاب الوصول إلى مقالاتهم الخاصة التي تم إنشاؤها:

عند هذه النقطة، نحن قد أتممنا تنفيذ RBAC. يمكنك الاطلاع على الشفرة المصدرية الكاملة لرؤية التنفيذ الكامل.

اختبار تنفيذ RBAC لنظام CMS#

الآن، دعونا نختبر تنفيذ RBAC لنظام CMS باستخدام المستخدمين الثلاثة الذين أنشأناهم للتو.

أولاً، دعونا نقوم بتسجيل الدخول كلاً من أليكس وتشارلي على التوالي وإنشاء بعض المقالات.

نظرًا لأن أليكس يمتلك دور المدير، فيمكنه إنشاء، حذف، تحديث، نشر، وعرض جميع المقالات.

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

بوب، الذي يمتلك دور الناشر، يمكنه عرض ونشر جميع المقالات لكن لا يمكنه إنشاء، تحديث، أو حذفها.

الخاتمة#

تهانينا! لقد تعلمت كيفية تنفيذ نظام RBAC قوي في تطبيقك.

بالنسبة للسيناريوهات الأكثر تعقيدًا، مثل بناء تطبيقات متعددة المستأجرين، يوفر Logto دعم شامل للمنظمات. تحقق من دليلنا بناء تطبيق SaaS متعدد المستأجرين: دليل كامل من التصميم إلى التنفيذ لتتعلم المزيد عن تنفيذ التحكم في الوصول على مستوى المنظمة.

برمجة سعيدة! 🚀