كيفية تأمين Microservices على AWS باستخدام Cognito و API Gateway و Lambda

دعني ادخل! (Giphy)

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

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

سننشئ تطبيقًا بسيطًا ونهيئ AWS لمصادقة مستخدم وتأمين خدمة microservice.

TL ؛ DR (لفارغ الصبر)

عرض توضيحي للعمل: https://auth-api-demo.firebaseapp.com/ (المستخدم: كلمة مرور demouser: demoPASS123)

جيثب ريبو: https://github.com/csepulv/auth-api-demo

حالة الاستخدام / الافتراض الأساسي: هناك مجموعتان من الموارد - أ) تلك التي تحتاج إلى مستخدم مصادق عليه و ب) تلك التي لا تحتاج إليها.

سوف نستخدم

  • AWS Lambda و API Gateway و Cognito
  • Claudia.js (لبناء API لدينا)
  • الرد (على عميل الويب الخاص بنا)

بالنسبة لأولئك الذين يقرؤون حتى النهاية ، هناك بعض الأشياء الجيدة.

الآن ، للحصول على التفاصيل.

نموذج التطبيق المفاهيمي

يقوم التطبيق التجريبي بتنفيذ النموذج التالي.

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

خدمات AWS

إذا كنت جديدًا على AWS ، فهناك البوابة الرسمية لـ AWS Getting Started. أيضا ، Udemy لديه دورة مجانية ، AWS أساسيات.

ستحتاج إلى الوصول إلى حساب AWS. يمكنك الاشتراك في فئة AWS المجانية.

AWS لامدا

في حين أن EC2 هو واحد من أكثر خيارات AWS شعبية ، أعتقد أن Lambda أكثر ملاءمة للخدمات الميكروية. مثيلات EC2 هي أجهزة افتراضية. أنت مسؤول عن كل شيء من نظام التشغيل إلى جميع البرامج التي يتم تشغيلها. Lambda هي وظيفة كنموذج الخدمة. لا يوجد خادم توفير أو نشر ؛ تكتب منطق خدمتك.

لمزيد من المعلومات ، راجع مستندات AWS Lambda.

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

بوابة API AWS

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

AWS Cognito

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

إعداد التطبيق والبيئة

عناصر التطبيق

الوصفة لتطبيقنا التجريبي هي:

  1. في AWS Cognito ، قم بإنشاء تجمع مستخدم (مع تطبيق عميل) وتجمع هوية متحد.
  2. في AWS API Gateway ، قم بإنشاء خطة استخدام ومفتاح API
  3. باستخدام Claudia JS ، قم ببناء ونشر واجهة برمجة تطبيقات بسيطة تعتمد على AWS Lambda.
  4. قم بتحديث دور AWS IAM لمنح المستخدمين المصادق عليهم حق الوصول إلى أساليب API المحمية
  5. قم بإنشاء تطبيق صفحة واحدة (SPA) باستخدام تطبيق create-react-app. سيستخدم AWS Cognito ويجعل طلبات واجهة برمجة التطبيقات الموقعة (والمصادقة)

إعداد AWS المفصل موجود في aws-setup.md ، في عرض GitHub التجريبي. سنقوم بتسليط الضوء على جوانب الإعداد وشرح الأمور تعمل.

AWS Cognito

تجمع المستخدم ، تطبيق العميل ، واسم المجال

سنقوم بإنشاء تجمع مستخدم مع الإعدادات الافتراضية. التفاصيل والصور:

  • تجمع المستخدم
  • تطبيق العميل
  • اسم النطاق

تجمع الهوية الموحدة

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

  • توفر تجمعات المستخدمين إمكانية وصول المستخدم إلى التطبيق. هذا مثل الخدمات مثل Auth0.
  • يوفر تجمع الهوية الموحد الوصول إلى موارد AWS.

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

الإعداد التفصيلي لتجمع هوية الاتحاد هو هنا.

بوابة API AWS

أقترح إنشاء خطة استخدام لواجهة برمجة التطبيقات لدينا. رغم أنها ليست متطلبًا ، فهي ممارسة جيدة ، لأن تكاليف AWS يمكن أن "تهرب" إذا لم تكن حريصًا. سنقوم بإنشاء "خطة الاستخدام" ، المسماة api-auth-demo وتعيين معدل الكبح والانفجار ، وحصة يومية لمكالمات API. سنقوم أيضًا بإنشاء مفتاح API ، والذي سيستخدمه تطبيق عميل الويب. (تفاصيل الإعداد الكاملة هنا.)

حدود المعدل والحصص

لقد انتهينا من الجزء الأكبر من إعداد AWS. سنقوم الآن بكتابة وظائف Lambda الخاصة بنا ثم بناء تطبيق React على الويب.

AWS لامدا وكلوديا JS

سنكتب وظائف Lambda باستخدام Node.js. سيقوم Claudia.js بنشر Lambdas الخاصة بنا وتكوين بوابة API. (كملاحظة ، يوفر إطار عمل Serverless وظائف مماثلة.)

نحتاج فقط إلى واجهة برمجة تطبيقات بسيطة لمثالنا. سننشئ طريقتين لواجهة برمجة التطبيقات (مثل الخدمات المصغرة البسيطة): طريقة للمستخدمين المصادق عليهم والأخرى للضيوف.

سنستخدم Claudia API Builder ، والذي يتيح توجيه مسارات متعددة إلى لامدا واحدة. تشبه آلية التوجيه التوجيه في الأطر مثل Express.js.

سنستخدم سطر أوامر Claudia.js لنشر واجهة برمجة التطبيقات في AWS.

claudia create --region us-west-2 - api-module api --name auth-api-demo

ملاحظة: سوف تحتاج إلى إعادة نشر أي تغييرات تطرأ على api.js. تحديث Useclaudia ...

مفاتيح API والمصادقة

في api.js ، يشير {apiKeyRequired: true} إلى أن طلبات API تتطلب مفتاح API. يقوم {AuthorizationType: 'AWS_IAM'} بتكوين بوابة API للتخويل باستخدام AWS IAM. آلية المصادقة الأساسية ليست واضحة. تحدد مستندات AWS النهج ، ولكن الموجز هو:

  • عند تسجيل دخول المستخدم ، ستصدر Cognito الرموز المميزة لبيانات الاعتماد المؤقتة (التي يتم الحصول عليها عبر STS).
  • بالنسبة للموارد المحمية ، يحتاج التطبيق إلى توقيع الطلبات باستخدام بيانات الاعتماد هذه
  • AWS فك شفرة والتحقق من التوقيع
  • إذا كان التوقيع صالحًا ، فإن بوابة API ترسل الطلب

هناك طرق الترخيص الأخرى المتاحة. تحدد مستندات Claudia.js كيفية تحديد طرق أخرى. (مستندات AWS المقابلة موجودة هنا.)

AWS أدوار IAM للمستخدمين المصادق عليهم

نحتاج إلى تعديل امتيازات أدوار IAM للمستخدمين المصادق عليهم. نحتاج إلى السماح باستدعاء طريقة بوابة API التي أنشأناها.

نحن بحاجة إلى ARN من بوابة API. انتقل إلى وحدة التحكم API Gateway وابحث عن مورد / طريقة API Gateway.

ARN (موضحة في الصورة)
  • نسخ ARN
  • انتقل إلى وحدة التحكم في IAM وابحث عن دور Authenticated الذي تم إنشاؤه أثناء إعداد Cognito Federated Identity Pool
  • إضافة سياسة مضمنة على النحو التالي
أدخل ARN تم نسخه من مورد بوابة API (في المنطقة المميزة)
  • حدد ARN المنسوخة لمورد API Gateway في السياسة.

يمكن للمستخدمين المصادق عليهم الآن استدعاء طرق API المحمية الخاصة بنا.

خدمة التحكم في الوصول إلى الخدمة

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

أنشأ Claudia.JS دور IAM لوظيفة Lambda. (يمكنك أيضًا إنشاء هذا الدور يدويًا وتحديد معرفه إلى Claudia.JS عبر المعلمة --role. التفاصيل هنا.)

إذا كانت وظيفة Lambda لدينا تحتاج إلى الوصول إلى موارد AWS الأخرى ، فسنحتاج إلى تحديث دور IAM الخاص بـ Lambda وتوفير هذه الامتيازات. قد تكون هذه قاعدة بيانات RDS ، على سبيل المثال.

تستخدم AWS دائمًا IAM لتكوين الخدمة للتحكم في الوصول إلى الخدمة. إنه نموذج متطور وموثق جيدًا. من المحتمل أن تكون الآلية الأساسية للتحكم في الوصول بين الخدمات الصغيرة (داخل AWS). قد تكون هناك حالات تحتاج إلى زيادتها أو استبدالها ، لكنني سأبدأ بـ IAM.

يمكننا الآن إنشاء تطبيق ويب لمستخدمينا.

رد تطبيق الويب

سأقوم بإنشاء تطبيق React صفحة ويب واحدة (SPA). A Vue.js أو تطبيق الزاوي ستعمل أيضا. بالنسبة لتطبيق العميل ، يوجد مكونان مهمان: AWS Amplify ووحدة aws4.

AWS Amplify يوفر سهولة التكامل مع AWS Cognito. aws4 هي مكتبة شائعة للتوقيع على طلبات AWS باستخدام AWS Version تواقيع الإصدار 4. AWS تستخدم الطلبات الموقعة للموارد المحمية (أي طلبات المستخدم المصرح بها).

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

للمصادقة ، نحن بحاجة إلى القيام ببعض إدارة الدولة. لا يستخدم تطبيق المثال أي إطار عمل ، ولكن في تطبيق حقيقي أقترح Mobx (أو Redux.)

في التطبيق التجريبي ، تدير auth-store.js حالة مصادقة المستخدم. يتكون هذا من حالة مصادقة المستخدم وبيانات الاعتماد. هذه تستخدم ل

  • تقديم مكونات وأنماط مختلفة لمستخدم مصادق مقابل مستخدم ضيف
  • توقيع طلبات أساليب API المحمية

بينما تدير AWS Amplify الكثير من تكامل AWS Cognito ، هناك بعض الأعمال التي يتعين علينا القيام بها.

تحديد حالة المصادقة من AWS Amplify

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

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

فئة Hub في الوحدة النمطية aws- تضخيم يتصرف مثل باعث الحدث. نحن نهتم بحدثين: تكوين و cognitoHostedUI.

تحميل الصفحة / تكوين تسلسل

بعد تهيئة AWS Amplify لمكون Auth ، يقوم بإصدار الحدث المكوّن. يمكن لطلبنا بعد ذلك الاستفسار عن حالة مصادقة المستخدم الحالي. هذا مفيد عندما يتم تحميل تطبيقنا ، على سبيل المثال.

تسجيل الدخول / تسلسل تغيير حالة مصادقة

أثناء استخدام التطبيق ، نحتاج إلى معرفة ما إذا كانت حالة المصادقة تتغير. يوجد حدث لتسجيل الدخول ، ولكنه ليس الحدث الذي نريده ، حيث يستخدم تطبيقنا التجريبي OAuth و UI Cognito Hosted. يتم استخدام حدث تسجيل الدخول في شاشة مخصصة لتسجيل الدخول / المتابعة أو عند استخدام واجهة المستخدم المدمجة لتضخيم التفاعل. بالنسبة إلى OAuth ، يرسل Amplify حدث cognitoHostedUI بعد تدفق تسجيل دخول OAuth مكتمل.

طلبات التوقيع

سيكون لدى المستخدم الحالي بيانات اعتماد صادرة عن AWS Cognito. هذه تحتوي على معرف وصول ومفتاح سري ومفتاح جلسة. تتوفر هذه عن طريق استدعاء Auth.currentCredentials () في aws- تضخيم. بالنسبة لأساليب واجهة برمجة التطبيقات التي أذن بها IAM ، تحتاج إلى توقيع الطلب باستخدام توقيعات AWS V4. لحسن الحظ ، فإن وحدة aws4 تتعامل مع تعقيدات توليد هذه التوقيعات.

في api-client.js ،

عرض

يمكننا أخيرا تشغيل npm start وتشغيل التطبيق! عندما نصل إلى التطبيق لأول مرة ، نحن ضيف (مستخدم غير مصادق). يمكنك أيضًا الانتقال إلى https://auth-api-demo.firebaseapp.com/ لتجربته.

يمكننا الوصول إلى طرق غير محمية.

مصادقة غير مطلوب

ولكن إذا حاولنا الوصول إلى مورد محمي ، فسوف يفشل.

غير مصدق

ولكن إذا سجلنا الدخول ، يمكننا الوصول إلى الموارد المحمية.

انقر فوق تسجيل الدخول واستخدم demouser بكلمة مرور demoPASS123.

بعد تسجيل الدخول - تعكس الأزرار حالة مصادقة

يمكننا الآن النقر فوق Req. زر المصادقة للوصول إلى طريقة API محمية.

يا للعجب! كان علينا تكوين خدمات متعددة واستيعاب الكثير من المعلومات. ولكن لدينا الآن تطبيقًا يمثل نموذجًا لمصادقة الخدمات الصغيرة على AWS.

Giphy

ماذا الآن؟

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

ولأولئك الذين بقوا معي حتى النهاية ، لديّ بعض هدايا الفراق.

  • في العرض التوضيحي ، يوجد برنامج نصي لأتمتة إعداد AWS. README به تفاصيل لتشغيله.
  • resources-cheatsheet.md لديه روابط محددة لـ AWS ذات الصلة ، و Claudia.js ، وما إلى ذلك من الوثائق.

شكرا للقراءة! (عدد قليل هي دائما موضع تقدير. )