بوابة API: المصادقة

Yong Qian

November 25, 2022

Technology

أهمية المصادقة والتفويض لبوابات API

يمكن تلخيص الوظيفة الأساسية لبوابة API في ربط مستهلكي API مع موفري API.

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

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

مصادقة بوابة API

المصادقة والتفويض في Apache APISIX

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

  1. الواجهة مع خدمات المصادقة الخارجية

خدمة المصادقة الخارجية

  1. المصادقة الداخلية للبوابة عبر كائن Consumer المصمم من قبل APISIX

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

سيتم تقديم هاتين الطريقتين للمصادقة بالتفصيل.

الواجهة مع خدمات المصادقة الخارجية

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

على سبيل المثال، يمكننا استخدام إضافة openid-connect للواجهة مع أي خدمة مصادقة تدعم بروتوكول OIDC. فيما يلي نموذج تكوين للواجهة مع خدمة keycloak:

curl http://127.0.0.1:9180/apisix/admin/routes -H "X-Api-Key: your-API-key" -XPOST -d '
{
    "uri":"/*",
    "plugins":{
        "openid-connect":{
            "client_id":"apisix", // يتم إنشاؤه عند إنشاء عميل في keycloak
            "client_secret":"d5c42c50-3e71-4bbe-aa9e-31083ab29da4",
            "discovery":"http://keycloak:8080/auth/realms/apisix_test_realm/.well-known/openid-configuration", // نقطة نهاية OpenID لـ keycloak
            "scope":"openid profile",
            "bearer_only":false,
            "realm":"apisix_test_realm",
            "introspection_endpoint_auth_method":"client_secret_post",
            "redirect_uri":"http://127.0.0.1:9080/"
        }
    },
    "upstream":{
        ...
    }
}'

المصادقة الداخلية للبوابة

Consumer

Consumer

عند وصول الطلبات من مصادر مختلفة إلى بوابة API، يجب على البوابة تحديد هذه المتصلين. تقترح Apache APISIX مفهوم "Consumer" لتمثيل المتصلين بنوع معين من الخدمات.

يتطلب كائن Consumer تكوين إضافة مصادقة للاستخدام. لنأخذ إضافة key-auth البسيطة كمثال:

$ curl http://127.0.0.1:9180/apisix/admin/consumers  -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "auth-jack"
        }
}'

التكوين أعلاه يعني أنه عندما يحمل الطلب المفتاح المحدد (auth-jack)، سيتم ربط الطلب الحالي بـ Consumer - jack. كما ترى، فإن إضافة المصادقة المكونة على Consumer هي في الواقع بيانات اعتماد الهوية تحت آلية مصادقة محددة. في إضافة key-auth، المفتاح هو بيانات الاعتماد التي تحدد مستهلكًا، تشبه اسم المستخدم وكلمة المرور في إضافة basic-auth.

تكوين إضافة المصادقة للطريق

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

$ curl http://127.0.0.1:9180/apisix/admin/routes/orders -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
    "uri": "/orders",
    "plugins": {
        "key-auth": {
            "header": "Authorization"
        }
    }
}'

التكوين أعلاه يعني أن إضافة key-auth تم تمكينها على الطريق /orders، وتأثير المصادقة هو كما يلي:

$ curl http://127.0.0.1:9080/orders -H 'Authorization: auth-jack' -i
HTTP/1.1 200 OK
...
$ curl http://127.0.0.1:9080/orders -H 'Authorization: wrong-key' -i
HTTP/1.1 401 Unauthorized
...
{"message":"Invalid API key in request"}

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

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

طرق المصادقة الرئيسية

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

Key Auth

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

Basic Auth

Basic Auth هي طريقة مصادقة تعتمد على اسم المستخدم وكلمة المرور، وغالبًا ما تستخدم في سيناريوهات تسجيل الدخول على الويب. على سبيل المثال، يمكن استخدام لوحة التحكم الإدارية لموقع ويب بعد تسجيل دخول المسؤول، حيث يمكننا استخدام Basic Auth للمصادقة.

LDAP

LDAP (بروتوكول الوصول إلى الدليل الخفيف الوزن) هو بروتوكول وصول إلى ملفات خفيف الوزن يعتمد على معيار X.500، ويوفر التحكم في الوصول وصيانة أدلة المعلومات الموزعة عبر بروتوكول IP. باستخدام LDAP، يمكن لمطوري التطبيقات والعمليات التحكم في وصول المستخدمين إلى الموارد على مستوى دقيق. باستخدام إضافة ldap-auth في APISIX، يمكنك بسهولة الواجهة مع المنصات التي تنفذ بروتوكول LDAP، مثل Active Directory من Microsoft، أو OpenLDAP Server لمنصات Linux، للتحكم بدقة في وصول المستهلكين إلى طرق محددة.

OIDC

OpenID هو نظام مصادقة عبر الإنترنت لامركزي. بالنسبة للمواقع التي تدعم OpenID، لا يحتاج المستخدمون إلى تذكر رموز المصادقة التقليدية مثل أسماء المستخدمين وكلمات المرور. بدلاً من ذلك، يحتاجون فقط إلى التسجيل مسبقًا في موقع يعمل كمزود هوية OpenID (IdP)، ويمكنهم بعد ذلك استخدام هذا الحساب لتسجيل الدخول إلى جميع التطبيقات التي تتعامل مع هذا المزود، على سبيل المثال، لمصادقة مستخدمي نظامنا الخاص من خلال حسابات خدمات Google أو Facebook المعروفة.

بالنسبة لـ OIDC، توفر APISIX إضافة openid-connect، والتي يمكن استخدامها للواجهة مع خدمات المصادقة التي تدعم بروتوكول OIDC.

Forward Auth

عندما لا تفي إضافة المصادقة القياسية في APISIX باحتياجاتك الحالية، أو إذا كانت هناك خدمة مصادقة مخصصة وغير قياسية موضوعة في نظامك، يمكنك التفكير في استخدام إضافة forward-auth. باستخدام هذه الإضافة، يمكنك تحويل طلبات المستخدمين إلى خدمة المصادقة عبر HTTP وإرجاع أخطاء مخصصة أو توجيه المستخدمين إلى صفحة المصادقة إذا استجابت خدمة المصادقة بحالة غير طبيعية (رمز خطأ غير 20x).

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

الربط مع الإضافات الأخرى بعد المصادقة

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

ACL (consumer-restriction)

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

القائمة البيضاء

في هذه الحالة، يمكننا استخدام إضافة consumer-restriction المقدمة من APISIX لتنفيذ آلية التحكم في الوصول.

$ curl http://127.0.0.1:9180/apisix/admin/routes -H 'X-API-KEY: your-API-key' -X POST -i -d '
{
    "uri": "/api/v1/users/admin",
    "plugins": {
        "key-auth": {},
        "consumer-restriction": {
            "whitelist": [
                "Rose",
                "Peter
            ]
        }
    },
    "upstream": {
        ...
    },
}'

الطريق أعلاه يقيد واجهة برمجة التطبيقات /api/v1/users/admin لتتطلب مصادقة key auth عبر إضافات key-auth و consumer-restriction، ويمكن فقط لـ Rose و Peter الوصول إليها.

تحديد المعدل (limit-count)

وصفنا سابقًا أنه يمكنك ربط بيانات اعتماد المستخدم مع المستهلكين من خلال تكوين إضافات المصادقة في Consumer، ولكن الحقيقة هي أن كائنات Consumer في APISIX يمكنها تحميل ليس فقط إضافات المصادقة، ولكن أيضًا أي إضافات مثل Route و Service.

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

$ curl http://127.0.0.1:9180/apisix/admin/consumers  -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "jack"
        },
        "limit-count": {
            "count": 200,
            "time_window": 60,
            "rejected_code": 503,
            "key": "$consumer_name",
        }
}'
$ curl http://127.0.0.1:9180/apisix/admin/consumers  -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
    "username": "rose",
    "plugins": {
        "key-auth": {
            "key": "rose"
        },
        "limit-count": {
            "count": 1000,
            "time_window": 60,
            "rejected_code": 503,
            "key": "$consumer_name",
        }
}'

مع التكوين أعلاه، قمنا بتحديد سياسات تحديد معدل مختلفة لـ jack و rose، حيث يتمتع rose بحصة طلبات أعلى تبلغ 1000 في 60 ثانية، بينما يتمتع jack فقط بـ 200.

الخلاصة

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

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

  • إضافات مصادقة غنية جاهزة للاستخدام
  • دعم طرق المصادقة المدمجة والخارجية، والتي يمكن للمستخدمين الاختيار منها بحرية
  • دعم التطوير الثانوي، وسهولة الواجهة مع مراكز المصادقة المخصصة

يمكن أن تساعد هذه المزايا الشركات على تنفيذ المصادقة والتفويض على مستوى البوابة بسهولة أكبر وتعزيز أمان API.

نرحب بكم لمعرفة المزيد عن Apache APISIX. يمكنكم التواصل معنا عبر https://api7.ai/contact.

Tags:
Authentication & Authorization
OIDC
API Gateway Concept