Forward-Auth، خيار آخر لوظيفة المصادقة

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

المبدأ

يظهر الشكل أعلاه مبدأ وتدفق forward-auth plugin في Apache APISIX، ويتم تلخيصه في الخطوات التالية.

• الخطوة 1: يقوم العميل بإرسال طلب إلى APISIX
• الخطوة 2: تقوم APISIX بإرسال طلب إلى خدمة المصادقة التي تم تكوينها من قبل المستخدم
• الخطوة 3: تستجيب خدمة المصادقة (حالة 2xx أو حالة استثناء)
• الخطوة 4: بناءً على استجابة خدمة المصادقة، ستقرر APISIX إما إعادة توجيه الطلب إلى المصدر العلوي أو إرسال استجابة رفض مباشرة إلى العميل

كيفية الاستخدام

الخطوة 1: إعداد خدمة المصادقة

لنفترض وجود خدمة مصادقة يتم إرسال طلب إليها من قبل المستخدم مع رأس طلب Authorization. إذا تمت المصادقة على هذه البيانات بنجاح، يتم إرجاع رمز حالة 200 ورأس استجابة باسم X-User-ID؛ إذا لم تتم المصادقة، يتم اعتبار حالة المصادقة منتهية الصلاحية ويتم إرجاع رمز حالة 302 ورأس استجابة Location لإعادة توجيه العميل إلى صفحة تسجيل الدخول.

الخطوة 2: إنشاء مسار وتمكين مكون forward-auth الإضافي

بعد ذلك، سنقوم بتكوين مسار وتمكين مكون forward-auth الإضافي للربط بين خدمة المصادقة المذكورة أعلاه والتطبيق العلوي.

curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
        "forward-auth": {
            "address": "http://127.0.0.1:9080/auth",
            "request_headers": ["Authorization"],
            "upstream_headers": ["X-User-ID"],
            "client_headers": ["Location"]
        }
    },
    "uri": "/user"
}'

تفاصيل التكوين أعلاه موضحة كالتالي:

• عند مطابقة طلب مع المسار الحالي، يتم إرسال طلب إلى العنوان المحدد في address مع رأس الطلب Authorization المحدد في request_headers (أي رأس الطلب الذي تم تكوينه لإعادة توجيهه من العميل إلى خدمة المصادقة، إذا لم يتم تعيينه، فلن يتم إعادة توجيه أي رأس طلب)، حيث يمكن لخدمة المصادقة تأكيد هوية المستخدم.
• إذا نجحت المصادقة، يتم إرجاع رمز حالة 200 ورأس X-User-ID كما هو محدد في upstream_headers (أي رأس الطلب الذي سيتم إعادة توجيهه إلى المصدر العلوي من قبل خدمة المصادقة عند نجاح المصادقة، إذا لم يتم تعيينه، فلن يتم إعادة توجيه أي رأس طلب).
• إذا فشلت المصادقة، يتم إرجاع رمز حالة 302 ورأس Location كما هو محدد في client_headers (أي رأس الاستجابة الذي يتم إرساله من خدمة المصادقة إلى العميل في حالة فشل المصادقة، أو لا يتم إرسال أي رأس استجابة إذا لم يتم تعيينه).

الخطوة 3: اختبار الطلبات

# إرسال طلب باستخدام POST
curl http://127.0.0.1:9080/user \
    --header 'Authorization: true'

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 28
Server: APISIX/2.11.0

{"user_id":"i-am-real-user"}

# إرسال طلب باستخدام GET
curl -i http://127.0.0.1:9080/user \
    --header 'Authorization: false'

HTTP/1.1 302 FOUND
Server: APISIX/2.11.0
Location: https://example.com/auth

ملحق: تعطيل المكون الإضافي

إذا كنت قد انتهيت من استخدام مكون Forward Auth الإضافي، ما عليك سوى إزالة تكوين مكون forward-auth الإضافي من تكوين المسار وحفظه لإيقاف تشغيل مكون Forward Auth الإضافي على المسار.

بفضل الطبيعة الديناميكية لـ Apache APISIX، ليست هناك حاجة لإعادة تشغيل Apache APISIX لتشغيل أو إيقاف تشغيل المكون الإضافي.

الخلاصة

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

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