الغوص العميق في المصادقة في أنظمة Microservices

ما هي خدمة المصادقة

المصادقة هي عملية التحقق من هوية المستخدم لمنحه الوصول والأذونات اللازمة لاستخدام النظام. الخدمة التي توفر هذه الوظيفة هي خدمة المصادقة. في تطبيق برمجي تقليدي أحادي (monolithic)، كل هذا يحدث داخل نفس التطبيق، ولكن في هندسة الخدمات المصغرة (microservices architecture)، يتكون النظام من خدمات متعددة. كل خدمة مصغرة لها مهامها الخاصة في مثل هذه الهندسة، لذا فإن تنفيذ عملية التفويض والمصادقة بشكل منفصل لكل خدمة مصغرة لا يعمل بشكل كامل.

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

خدمة المصادقة في الهندسة التقليدية

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

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

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

"ناقل خدمة المؤسسة" هو قناة تربط بين خدمات المؤسسة المختلفة. وجود ESB يهدف إلى دمج خدمات مختلفة ذات بروتوكولات مختلفة. يوفر ESB خدمات مثل ترجمة وتوجيه طلبات العملاء، بحيث يمكن للخدمات المختلفة أن تترابط بسهولة. كما يمكن أن تخمن من الاسم، فإن مفهومه مستوحى من نموذج الاتصال في مبادئ تكوين الحاسوب - الناقل (bus)، حيث تتصل جميع الأنظمة التي تحتاج إلى التواصل مع الأنظمة الخارجية بـ ESB. يمكنك استخدام النظام الحالي لبناء نظام موزع غير متجانس ذو اقتران فضفاض.

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

الهندسة الأحادية

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

هندسة ESB

في هندسة ESB، تتم جميع العمليات بين الخدمات عبر ناقل ESB. نظرًا لأن هندسة ESB مشتقة من الهندسة الأحادية، فإن طريقة المصادقة لم تتغير مقارنة بالهندسة الأحادية.

خدمة المصادقة في هندسة الخدمات المصغرة

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

يمكننا تقسيم خدمات المصادقة في هندسة الخدمات المصغرة إلى الفئات الثلاث التالية:

1. تنفيذ المصادقة في كل خدمة مصغرة
2. تنفيذ المصادقة من خلال خدمة مصادقة
3. تنفيذ المصادقة من خلال بوابة API

كل نهج له مزايا وعيوب محددة.

تنفيذ المصادقة في كل خدمة مصغرة

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

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

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

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

المزايا: التنفيذ السريع، الاستقلالية القوية

العيوب: تكرار التعليمات البرمجية بين الخدمات؛ انتهاك مبدأ المسؤولية الواحدة؛ صعوبة الصيانة

تنفيذ المصادقة من خلال خدمة مصادقة

نظرًا لصعوبة تنفيذ المصادقة في كل خدمة مصغرة بنفسها، واستخدام مكتبة مصادقة مشتركة ينتهك نية تقسيم الخدمات المصغرة، هل يمكن ترقية مكتبة المصادقة المشتركة إلى خدمة مصادقة مخصصة؟

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

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

المزايا: كل خدمة مصغرة لديها مسؤولية واحدة، والمصادقة مركزية

العيوب: نقطة فشل واحدة؛ زيادة زمن طلب الاستجابة

تنفيذ المصادقة من خلال بوابة API

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

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

على سبيل المثال، باستخدام APISIX's jwt-auth plugin، يمكننا تنفيذ المصادقة على البوابة.

1. يجب علينا تكوين عدة معلومات هوية المستخدم (الاسم، المفتاح، إلخ) على APISIX.
2. وفقًا للمفتاح المحدد للمستخدم، نبدأ طلب توقيع إلى APISIX للحصول على رمز JWT الخاص بالمستخدم.
3. ثم، عندما يحتاج العميل إلى الوصول إلى خدمة أعلى، فإنه يجلب رمز JWT، وتعمل APISIX كبوابة API لوكيل هذا الوصول.
4. أخيرًا، ستقوم APISIX بإكمال عملية المصادقة باستخدام رمز JWT.

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

المزايا: حماية فعالة للخدمات المصغرة الخلفية؛ لا تحتاج الخدمات المصغرة إلى التعامل مع أي منطق مصادقة

العيب: نقطة فشل واحدة

الخلاصة

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

1. تنفيذ المصادقة في كل خدمة مصغرة
2. تنفيذ المصادقة من خلال خدمة مصادقة
3. تنفيذ المصادقة من خلال بوابة API

كل خيار له مزايا وعيوب، والتي تحتاج إلى تحليل مفصل وفقًا للظروف.