خلفية
يسألني الأصدقاء الذين تحولوا من التطبيقات المتجانسة التقليدية إلى Spring Cloud ، وكيفية إدارة أذونات الخدمات الدقيقة تحت Spring Cloud ؟ كيف تصمم بشكل أكثر معقولًا؟ من منظور كبير ، يطلق عليه أذونات الخدمة ، والتي تنقسم إلى ثلاثة أجزاء:用户认证،用户权限،服务校验.
مصادقة المستخدم
قد تعتاد التطبيقات المتجانسة التقليدية على وجود جلسات. بعد الخدمات المجهرية لـ Spring Cloud ، يمكن حل الجلسات من خلال الجلسات الموزعة ، لكنها ليست أفضل استراتيجية بعد كل شيء. بدأ بعض الأشخاص في تنفيذ أمان الربيع السحابي الذي يجمع بشكل جيد مع OAuth2 . في وقت لاحق ، من أجل تحسين مشكلات تخزين Access Token في OAUTH 2 وتحسين توافر الخدمات الخلفية وقابلية التوسع ، هناك طريقة أفضل للتحقق من الرمز المميز JWT (JSON WEB TOKEN). شيء واحد يجب التأكيد عليه هنا هو أن OAuth2 و JWT غير قابلين للمقارنة على الإطلاق ، وهما شيئان مختلفان تمامًا.
OAuth2是一种授权框架، في حين أن JWT هو بروتوكول مصادقة
OAUTH2 Framework OAUTH2 يحتوي على أربعة أدوار:
OAUTH2 يحتوي على 4 أوضاع تفويض
من بينها ، تظهر عملية تشغيل OAUTH2 في الشكل أدناه ، مقتطفًا من RFC 6749:
+--------++----------------------+| |-(أ)-طلب التفويض-> | مورد || | | | | المالك || | <-(ب)-منح إذن --- | || | +------------------------+| || | +-------------------+| |-(ج)-منحة إذن-> | إذن || العميل | | | الخادم || | <-(D) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- مورد || | | الخادم || <-(F) --- مورد محمي --- | |+--------++-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
في Spring Cloud OAUTH2 ، تحمل جميع طلبات الوصول إلى موارد الخدمات الصغيرة الرموز الرموز في رأس HTTP. ستطلب الخدمة التي تم الوصول إليها بعد ذلك خادم التفويض للتحقق من صحة الرمز المميز. وبهذه الطريقة ، نحتاج إلى طلبين两次或者更多次. تقع جميع عمليات التحقق من صحة الرمز المميز على خادم التفويض ، الذي أصبح عنق الزجاجة كبيرًا جدًا للتوسع الأفقي لنظامنا.
بروتوكول شهادة JWT
يقوم授权服务器بتسلسل معلومات المستخدم ونطاق التفويض ويضع سلسلة JSON ، ثم يستخدم BASE64 لتشفيرها ، وأخيراً يوقع على السلسلة مع مفتاح خاص في خادم التفويض للحصول على JSON Web Token .
على افتراض أن جميع خوادم الموارد الأخرى ستعقد مفتاح RSA العمومي. عندما يتلقى خادم الموارد الطلب للحصول على رمز في رأس HTTP ، يمكن لخادم الموارد الحصول على الرمز المميز والتحقق مما إذا كان يستخدم توقيع المفتاح الخاص الصحيح (سواء تم توقيعه بواسطة الخادم المعتمد ، أي التحقق من التوقيع). بعد اجتياز التحقق ، سيتم الحصول على معلومات التحقق الصحيحة الموجودة في Toekn بعد التخلص من التسلسل.
من بينها ، المخطط الانسيابي للعملية الرئيسية على النحو التالي:
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
من خلال الطريقة أعلاه ، يمكننا إكمال مصادقة المستخدم المستندة إلى الخدمة بشكل جيد.
أذونات المستخدم
كل شخص يحب shiro للحصول على إذن من تطبيقات الجسد التقليدي ، وهو سهل الاستخدام. ولكن بمجرد الانقسام ، تبدأ الأذونات في أن تتناثر عبر واجهات برمجة التطبيقات المختلفة. هل ما زال shiro يعمل؟ في المشروع ، لم أستخدم shiro . بعد فصل النهايات الأمامية والخلفية ، يكون التفاعل رمزًا ، وخدمات الواجهة الخلفية عديمة الجنسية ، وأزرار الواجهة الأمامية ، وأين يمكننا إدارة الأذونات؟
الملخص والتصميم
قبل تقديم التصميم الأساسي المرن ، اسمحوا لي أن أقدم مفهوم المبتدئين لك: RBAC (التحكم في الوصول القائم على الأدوار ، والتحكم القائم على الأدوار) ، مما يعني أن المستخدمين يربطون بالأذونات من خلال الأدوار. ببساطة ، يتمتع المستخدم بعدة أدوار ، وكل دور له عدة أذونات.
RBAC هو في الواقع نموذج تحليلي ، مقسمة بشكل رئيسي إلى: النموذج الأساسي RBAC0 (CORE RBAC) ، دور النموذج الهرمي RBAC1 (RBAC الهرمي) ، نموذج تقييد الدور RBAC2 (القيد RBAC) ونموذج موحد RBAC3 (يجمع بين RBAC).
Core UML
هذا هو مخطط العلاقة RBAC المجردة للمؤلف بعد سيناريوهات أعمال متعددة
وصف الفصل
مجموعة
يمكن أن تكون مجموعة أو مجموعة ، مجموعة مع عدد معين من الأذونات ، حاملة للأذونات.
子类: المستخدم (المستخدم) ، الدور (الدور) ، الموضع (بعد) ، الوحدة (القسم). من خلال التكوين المحدد للمستخدم ، يتم تشكيل مجموعات أو مجموعات من سيناريوهات الأعمال المختلفة ، ويتم الحصول على أذونات المستخدمين من خلال إذن إلى الفئة الأم للمجموعة أو المجموعة.
إذن
يمكن أن تكون الأذونات ، والتكامل مع عدد معين من الموارد ، حاملة الموارد.
موارد
هناك موارد تحت الأذونات ، وتشمل مصادر الموارد: القائمة (القائمة) ، الزر (إذن الإجراء) ، عناصر الصفحة (زر ، علامة التبويب ، إلخ) ، أذونات البيانات ، إلخ.
برنامج
يمكن تركيب البرامج ، الناقل المقدم لعناصر التحكم في الإذن ذات الصلة ، في قوائم متعددة.
التكوين الأساسي لبرامج الويب المشتركة
العلاقة بين النموذج والخدمات الدقيقة
إذا تم تعريف جميع واجهات API بعد خدمة Spring Cloud Resources أعلاه ، فيمكننا رؤية مثل هذا الموقف.
على سبيل المثال ، إذا أضاف المستخدم ، يحذف ، تعديل وشيكات ، ستقوم صفحتنا بذلك.
| عناصر الصفحة | ترميز الموارد | الموارد URI | طريقة طلب الموارد |
|---|---|---|---|
| استفسار | user_btn_get | /API/user/{id} | يحصل |
| يزيد | user_btn_add | /API/المستخدم | بريد |
| يحرر | user_btn_edit | /API/user/{id} | يضع |
| يمسح | user_btn_del | /API/user/{id} | يمسح |
بعد الإخضاع في علاقة التعيين أعلاه ، تتم الرجوع إلى مواردنا الأمامية والخلفية ، مما يسهل علينا أن نخطر أذونات مجموعة المستخدمين. على سبيل المثال ، أمنح إذن المستخدم لإضافة وحذف. في前端نحتاج فقط إلى التحقق مما إذا كان资源编码موجودًا أم لا للتحكم في الشاشة وإخفاء الأزرار ، بينما في后端، نحتاج فقط إلى اعتراض موحد وتحديد ما إذا كان لدى المستخدم طريقة URI وطريقة请求方式المقابلة.
أما ما إذا كان يتم وضع اعتراض الإذن الموحد على بوابة Zuul أو وضعه على اعتراض خدمة الواجهة الخلفية المحددة (Filter ، Inteceptor) ، يمكن تنفيذها بسهولة. لا تقتصر على غزو الكود. المخطط الانسيابي لوضع Zuul كما يلي:
إذا تم وضع اعتراض الأذونات الموحدة على Zuul ، فستكون هناك مشكلة ، أي ما إذا كانت الخدمة الخلفية آمنة ، ولا تحتاج إلا إلى استدعاء الخدمة من خلال مركز التسجيل. يتضمن ذلك الوحدة الثالثة وراء المصادقة بين الخدمات.
المصادقة بين الخدمات
لأننا نعلم جميعًا أن الخدمات تسمى مباشرة عن بُعد بعد العثور على العميل من خلال مركز التسجيل. نحن بحاجة إلى حماية كل خدمة وواجهة حساسة في الإنتاج. عملية الموضوع هي كما يلي:
تعتمد طريقة تنفيذ المؤلف على FeignClient Inteceprot من Spring Cloud (تلقائيًا التقدم بطلب للحصول على رمز الخدمة ، وتمرير السياق الحالي) و Mvc Inteceptor (التحقق من الرمز المميز للخدمة ، وتحديث السياق الحالي) لزيادة حماية أمان الخدمة.
بعد الجمع بين ميزات Spring Cloud ، يكون مخطط التدفق الكلي كما يلي:
نقطة التحسين
على الرغم من أنه يتم ضمان أمان واجهة API من خلال التحقق من شرعية المستخدم المذكورة أعلاه ، واعتماد إذن المستخدم والمصادقة بين الخدمات ، Http访问频率مرتفع نسبيًا. عندما يزداد عدد الطلبات ، ستكون مشكلة慢واضحة بشكل خاص. يمكن النظر في بعض استراتيجيات التحسين ، مثل ذاكرة التخزين المؤقت لذنب المستخدم ، والتوزيع والتخزين المختلط لمعلومات ترخيص الخدمة ، والتحديث المنتظم لرموز مصادقة الخدمة.
خاتمة
ما سبق هو فكرتي العامة في المشروع. يمكن للأصدقاء المهتمين التعلم من مشروعي مفتوح المصدر. مرحبا بكم في ستار:
- Gitchina: https://gitee.com/minull/ace-security (JWT ، أذونات المستخدم)
- github: https://github.com/wxiaoqi/ace-security
- Gitchina: http://git.oschina.net/GEEK_QI/ACE-GATE (مصادقة الخدمة)
ما سبق هو كل محتوى هذه المقالة. آمل أن يكون ذلك مفيدًا لتعلم الجميع وآمل أن يدعم الجميع wulin.com أكثر.