Product-apim: دعم المصادقة الأساسية للمشتركين

يدعم الإصدار 3.0.0 APIM الذي تم إصداره حديثًا المصادقة الأساسية. نحن نستخدمه حاليًا في بيئتنا.

نعم لنقاط النهاية الخلفية. بالنسبة إلى Api ، لم أتمكن من العثور على الخيار.

ناشر API -> تكوينات وقت التشغيل -> أمان مستوى التطبيق

@ Tomas-Mrazek صحيح ، الآن نحن ندعم المصادقة الأساسية لعملاء API أيضًا. يمكنك تمكين الخيار Basic ضمن أمان مستوى التطبيق كما هو موضح أعلاه. سيسمح ذلك لمستهلكي واجهة برمجة التطبيقات (API) باستدعاء واجهة برمجة التطبيقات هذه باستخدام تركيبة كلمة مرور اسم المستخدم الخاصة بهم.

حسنًا ، يبدو أنني كنت أبحث في نفس المكان. فقط اختبرته وهو يعمل.

هذا يجلب المزيد من الأسئلة.

كيف تعمل الاشتراكات مع المصادقة الأساسية؟ يبدو أن أي مستخدم يمكنه استدعاء أي Api ، بغض النظر عن الاشتراكات؟ هل هناك طريقة "لتعيين" مستخدمين لتطبيقات معينة بحيث يمكنهم استدعاء واجهة برمجة التطبيقات (API) فقط التي تم الاشتراك فيها؟

إذا كان كل من Prod و Sandbox يشتركان في نفس البوابة ، فكيف يتم تحديد أيهما يتم استدعاؤه عند إجراء المصادقة الأساسية؟

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

ربما أفتقد شيئًا ما ، لذا سيكون من الجيد أن تدلني على الوثائق.

كيف تعمل الاشتراكات مع المصادقة الأساسية؟ يبدو أن أي مستخدم يمكنه استدعاء أي Api ، بغض النظر عن الاشتراكات؟ هل هناك طريقة "لتعيين" مستخدمين لتطبيقات معينة بحيث يمكنهم استدعاء واجهة برمجة التطبيقات (API) فقط التي تم الاشتراك فيها؟

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

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

إذا كان كل من Prod و Sandbox يشتركان في نفس البوابة ، فكيف يتم تحديد أيهما يتم استدعاؤه عند إجراء المصادقة الأساسية؟

سؤال جيد. لا اعرف الجواب.

بالمناسبة ، هذا لن يعمل مع مفتاح وسر المستهلك. يتم تحديد نقطة النهاية أثناء / إنشاء الرمز المميز AFAIK.

مرحبًا @ Tomas-Mrazek و tmkasun ، هذه بالضبط

OAuth2 -

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

المصادقة الأساسية كما هي الآن - سأطلق عليها "المصادقة الأساسية القائمة على المستخدم". إنه يتخلى تمامًا عن مفهوم التطبيق والاشتراك ، ويتطلب استخدام مفهوم مختلف (أذونات قائمة على المستخدم) وأدوات مختلفة مثل استخدام Carbon admin بدلاً من Publisher أو Store / DevPortal. ولا يمكن التمييز بين بيئة الإنتاج وبيئة الحماية عند استخدام بوابة واحدة لكليهما. كما أنه يعطي مستوى إضافيًا من التعقيد في الإعداد والإدارة. الآن لا يكفي إلقاء نظرة على قائمة التطبيقات المشتركة ، يجب على المرء أيضًا الانتقال إلى مسؤول الكربون والنظر إلى المستخدمين والأذونات. وإذا كنت أرغب في تحديد تطبيق محدد واحد لواجهة برمجة تطبيقات ، أو لدي مستويات اشتراك مختلفة ، فلا يمكنني فعل ذلك للمستخدم.

ما أرى أنه طريقة "صحيحة" لدعم المصادقة الأساسية سيكون على النحو التالي:

المصادقة الأساسية على مستوى التطبيق - نخرج المستخدم من المفهوم (مثل المفاتيح الثابتة) ونستخدم مصادقة التطبيق بدلاً من ذلك. لا يزال التطبيق بحاجة إلى الاشتراك في Api. يتم استخدام مفتاح العميل وسر العميل كأوراق اعتماد أساسية للمصادقة. بهذه الطريقة نحافظ على مفهوم اشتراك التطبيق / Api ، يمكننا الاستمرار في استخدام نفس الأدوات المستخدمة في كل شيء آخر (الناشر / devPortal ، لا حاجة إلى Carbon Admin) ، ونعرف التطبيق الذي يستخدم أي تطبيق Api وأي بيئة تعتمد على المفاتيح.

كيفية الوصول الى هناك؟

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

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

مرحبًا @ Tomas-Mrazek وmarkokocic
شكرًا لك على اقتراحاتك ، يرجى العثور على إجاباتي مضمنة.

كيف تعمل الاشتراكات مع المصادقة الأساسية؟ يبدو أن أي مستخدم يمكنه استدعاء أي Api ، بغض النظر عن الاشتراكات؟ هل هناك طريقة "لتعيين" مستخدمين لتطبيقات معينة بحيث يمكنهم استدعاء واجهة برمجة التطبيقات (API) فقط التي تم الاشتراك فيها؟

لا يتطلب دعم المصادقة الأساسي لطلبات العميل وجود اشتراكات. إذا قام منشئ واجهة برمجة التطبيقات بتمكين دعم المصادقة الأساسية لواجهة برمجة تطبيقات معينة ، فيمكن استدعاء واجهة برمجة التطبيقات هذه دون الاشتراك في واجهة برمجة التطبيقات (بواسطة التطبيق).
و markokocic نعم ، كيف يعمل الاشتراك ، An Application subscribed to an API .

علاوة على ذلك مع مصادقة Baisc:
ما زلت تحصل على:

• مستوى المورد أو مستوى واجهة برمجة التطبيقات
• التحقق من نطاق الموارد

لن تحصل على:

• تقييد مستوى الاشتراك
• تمايز بيئة الإنتاج و Sandbox

إذا كان كل من Prod و Sandbox يشتركان في نفس البوابة ، فكيف يتم تحديد أيهما يتم استدعاؤه عند إجراء المصادقة الأساسية؟

نعم ، لم نتمكن من تمييز البيئة عن طريق اسم المستخدم وكلمة المرور ، وبالتالي عند استخدام المصادقة الأساسية ، لن يكون لديك خيار تحديد البيئة ، وسيتم استخدام نقطة نهاية الإنتاج.

@ توماس مرزك

يتم تحديد نقطة النهاية أثناء / إنشاء الرمز المميز AFAIK.

لا ، يتم تحديد نقاط النهاية (Prod & Sandbox) بواسطة منشئ واجهة برمجة التطبيقات عند إنشاء واجهة برمجة التطبيقات ، ويمكن لمستهلكي واجهة برمجة التطبيقات توفير عنوان URL لمعاودة الاتصال لتطبيق ما إذا كانوا يريدون استخدام نوع (أنواع) المنح القائمة على إعادة التوجيه (i: e ضمني)

@ markokocic بخصوص

المصادقة الأساسية على مستوى التطبيق

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

المصادقة الأساسية على مستوى التطبيق

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

تضمين التغريدة
نعم ، من الممكن استخدام المصادقة الأساسية لإنشاء رمز مميز باستخدام بيانات اعتماد العميل. أنت تستخدم شيئًا مثل هذا:

curl -k -X POST https://localhost:8243/token -d "grant_type=client_credentials" -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

ومع ذلك ، لاستخدام واجهة برمجة التطبيقات ، لا يزال العميل بحاجة إلى أن يكون قادرًا على:

• قم بإنشاء الرمز المميز باستخدام الطريقة أعلاه
• قم بتعيينه كرأس http "ترخيص" مع Bearer و Token لطلب API الفعلي
• في النهاية يعتني بانتهاء صلاحية الرمز المميز وتحديثه

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

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

شيء مثل:

curl -k -X POST https://localhost:8243/my/nice/Api/doSomething -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

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

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

curl -k -X POST https://consumer-key:consumer-secret<strong i="25">@localhost</strong>:8243/my/nice/Api/doSomething

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