API7 Enterprise v3.2.15: المصادقة متعددة الاعتمادات

مع تزايد تعقيد خدمات API، لم تعد طرق التحكم في الوصول التقليدية التي تعتمد فقط على عناوين IP أو رؤوس الطلبات الأساسية كافية. تقدم API7 Enterprise مفهوم "المستهلكين"، مما يسمح للمطورين بربط المستهلكين بمسارات أو خدمات API محددة مع تمكين نفس إضافات المصادقة. عندما يقوم مستهلك بإرسال طلب، يحدد بوابة API المستهلك بناءً على بيانات الاعتماد المقدمة في الطلب ويطبق سياسات التحكم في الوصول المقابلة وفقًا لعلاقات الربط.

تعزز API7 Enterprise v3.2.15 آليات مصادقة المستهلكين الحالية. حيث تقوم بتحسين تفاعلات الإضافات الشائعة الاستخدام، وتحسين التحكم في الأذونات، وتدعم بيانات اعتماد مصادقة متعددة لكل إضافة. مما يتيح إدارة أكثر مرونة لبيانات الاعتماد وتناوبها.

تحسين تفاعل إضافة مصادقة المستهلكين

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

يدعم المستهلك حاليًا طرق المصادقة الأربعة التالية مع بيانات اعتماد متعددة.

مصادقة المفتاح

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

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

المصادقة الأساسية

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

في تكوين المسار أو الخدمة، يجب تمكين إضافة Basic Auth مع القواعد المناسبة للتحقق من معلومات المصادقة. يتحقق البوابة مما إذا كان الطلب يتضمن رأس Authorization ويتبع تنسيق المصادقة الأساسية. التنسيق هو Basic <encoded-value>، حيث <encoded-value> هو نتيجة تشفير Base64 لاسم المستخدم وكلمة المرور مفصولة بنقطتين. يقوم البوابة بفك تشفير هذه القيمة ومقارنة اسم المستخدم وكلمة المرور المفكوكة مع المعلومات المكونة. إذا تطابقت، يُسمح للطلب بالوصول إلى الخدمة الخلفية؛ إذا لم تتطابق، يتم رفض الطلب.

لاحظ أن المصادقة الأساسية تنقل اسم المستخدم وكلمة المرور كنص عادي، فقط مشفرة في Base64 (غير مشفرة)، مما يجعلها غير مناسبة لسيناريوهات الأمان العالية.

مصادقة JWT

مصادقة JWT هي طريقة تعتمد على رموز JSON Web Tokens (JWT). يجب على المستهلكين تضمين رمز JWT صالح في طلباتهم، عادةً في رأس Authorization باستخدام تنسيق Bearer <token> ولكن يمكن أيضًا وضعه في معلمات سلسلة الاستعلام أو ملفات تعريف الارتباط حسب الحاجة. يجب على المستهلكين التأكد من صحة وصحة رمز JWT عند تكوين الطلبات.

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

مصادقة HMAC

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

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

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

سياسات أذونات المستهلكين الدقيقة

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

الخلاصة

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

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