Share via

حول بيانات اعتماد واجهة برمجة التطبيقات ومدير بيانات الاعتماد

  • مقالة

ينطبق على: جميع مستويات إدارة واجهة برمجة التطبيقات

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

إشعار

  • حاليا، يمكنك استخدام إدارة بيانات الاعتماد لتكوين الاتصالات وإدارتها (التي كانت تسمى سابقا التخويلات) لواجهات برمجة تطبيقات OAuth 2.0 الخلفية.
  • لا يتم تقديم أي تغييرات فاصلة مع مدير بيانات الاعتماد. يستخدم موفرو بيانات اعتماد OAuth 2.0 والاتصالات واجهات برمجة تطبيقات تخويل APIM الحالية وموفر الموارد.

الاتصالات المدارة لواجهات برمجة تطبيقات OAuth 2.0

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

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

رسم تخطيطي لمدير بيانات اعتماد APIM وموفري هوية SaaS المدعومين.

أمثلة على حالات الاستخدام

باستخدام اتصالات OAuth المدارة في APIM، يمكن للعملاء الاتصال بسهولة بموفري SaaS أو خدمات الواجهة الخلفية التي تستخدم OAuth 2.0. إليك بعض الأمثلة:

  • الاتصال بسهولة بواجهة SaaS الخلفية عن طريق إرفاق رمز التخويل المخزن وطلبات الوكيل

  • طلبات الوكيل إلى تطبيق ويب Azure App Service أو الواجهة الخلفية ل Azure Functions عن طريق إرفاق رمز التخويل المميز، والذي يمكنه لاحقا إرسال الطلبات إلى خلفية SaaS تطبيق منطق التحويل

  • طلبات الوكيل إلى الواجهات الخلفية لاتحاد GraphQL عن طريق إرفاق رموز وصول متعددة لأداء الاتحاد بسهولة

  • كشف نقطة نهاية الرمز المميز للاسترداد، والحصول على رمز مميز مخزن مؤقتا، واستدعاء خلفية SaaS نيابة عن المستخدم من أي حساب، على سبيل المثال، تطبيق وحدة تحكم أو برنامج Kubernetes الخفي. اجمع SaaS SDK المفضل لديك بلغة مدعومة.

  • سيناريوهات Azure Functions غير المراقب عند الاتصال بخلفيات SaaS متعددة.

  • تحصل Durable Functions على خطوة أقرب إلى Logic Apps مع اتصال SaaS.

  • باستخدام اتصالات OAuth 2.0، يمكن أن تعمل كل واجهة برمجة تطبيقات في APIM كموصل مخصص ل Logic Apps.

كيف يعمل مدير بيانات الاعتماد؟

تتكون بيانات اعتماد الرمز المميز في إدارة بيانات الاعتماد من جزأين: الإدارة ووقت التشغيل.

  • يهتم جزء الإدارة في إدارة بيانات الاعتماد بإعداد وتكوين موفر بيانات اعتماد الرموز المميزة OAuth 2.0، وتمكين تدفق الموافقة لموفر الهوية، وإعداد اتصال واحد أو أكثر بموفر بيانات الاعتماد للوصول إلى بيانات الاعتماد. للحصول على التفاصيل، راجع إدارة الاتصالات.

  • يستخدم get-authorization-context جزء وقت التشغيل النهج لجلب وتخزين الرموز المميزة للوصول إلى الاتصال وتحديثه. عندما يأتي استدعاء إلى APIM، ويتم get-authorization-context تنفيذ النهج، فإنه يتحقق أولا ما إذا كان رمز التخويل الحالي صالحا. إذا انتهت صلاحية الرمز المميز للتخويل، تستخدم APIM تدفق OAuth 2.0 لتحديث الرموز المميزة المخزنة من موفر الهوية. ثم يتم استخدام الرمز المميز للوصول لتخويل الوصول إلى خدمة الواجهة الخلفية. للحصول على التفاصيل، راجع وقت تشغيل الاتصالات.

متى تستخدم إدارة بيانات الاعتماد؟

فيما يلي ثلاثة سيناريوهات لاستخدام إدارة بيانات الاعتماد.

سيناريو التكوين

بعد تكوين موفر بيانات الاعتماد والاتصال، يمكن لمدير واجهة برمجة التطبيقات اختبار الاتصال. يقوم مدير واجهة برمجة التطبيقات بتكوين واجهة برمجة تطبيقات OAuth خلفية اختبار لاستخدام get-authorization-context النهج باستخدام الهوية المدارة للمثيل. يمكن لمدير واجهة برمجة التطبيقات بعد ذلك اختبار الاتصال عن طريق استدعاء اختبار واجهة برمجة التطبيقات.

رسم تخطيطي لسيناريو التكوين الأولي لمدير بيانات الاعتماد.

سيناريو غير مراقب

بشكل افتراضي عند إنشاء اتصال، يتم تكوين نهج الوصول والاتصال مسبقا للهوية المدارة لمثيل APIM. لاستخدام مثل هذا الاتصال، قد يقوم مستخدمون مختلفون بتسجيل الدخول إلى تطبيق عميل مثل تطبيق ويب ثابت، والذي يستدعي بعد ذلك واجهة برمجة تطبيقات خلفية مكشوفة من خلال APIM. لإجراء هذا الاستدعاء، يتم تطبيق الاتصالات باستخدام النهج get-authorization-context . نظرا لأن استدعاء واجهة برمجة التطبيقات يستخدم اتصالا تم تكوينه مسبقا ولا يرتبط بسياق المستخدم، يتم إرجاع نفس البيانات إلى جميع المستخدمين.

رسم تخطيطي لسيناريو الهوية المدارة لمدير بيانات الاعتماد.

سيناريو الحضور (مفوض من قبل المستخدم)

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

رسم تخطيطي للسيناريو المفوض من قبل المستخدم لمدير بيانات الاعتماد.

كيفية تكوين إدارة بيانات الاعتماد؟

المتطلبات

  • يجب تمكين الهوية المُدارة المخصصة للنظام لمثيل إدارة واجهة برمجة التطبيقات.

  • يجب أن يكون لمثيل APIM اتصال صادر بالإنترنت على المنفذ 443 (HTTPS).

التوافر

  • جميع مستويات خدمة APIM

  • غير مدعوم في البوابة المستضافة ذاتيا

  • غير مدعوم في السحب السيادية أو في المناطق التالية: australiacentral، australiacentral2، indiacentral

أمثلة خطوة بخطوة

اعتبارات الأمان

يتم تشفير الرمز المميز للوصول والأسرار الأخرى (على سبيل المثال، أسرار العميل) باستخدام تشفير المغلف وتخزينها في تخزين داخلي متعدد المستأجرين. يتم تشفير البيانات باستخدام AES-128 باستخدام مفتاح فريد لكل بيانات. يتم تشفير هذه المفاتيح بشكل غير متماثل مع شهادة رئيسية مخزنة في Azure Key Vault وتدويرها كل شهر.

الحدود

Resource الحد
الحد الأقصى لعدد موفري بيانات الاعتماد لكل مثيل خدمة 1,000
الحد الأقصى لعدد الاتصالات لكل موفر بيانات اعتماد 10,000
الحد الأقصى لعدد نهج الوصول لكل اتصال 100
الحد الأقصى لعدد طلبات التخويل في الدقيقة لكل اتصال 250

الأسئلة الشائعة (FAQ)

متى يتم تحديث رموز الوصول المميزة؟

للاتصال برمز تخويل النوع، يتم تحديث رموز الوصول المميزة كما يلي: عند get-authorization-context تنفيذ النهج في وقت التشغيل، تتحقق إدارة واجهة برمجة التطبيقات مما إذا كان الرمز المميز للوصول المخزن صالحا. إذا انتهت صلاحية الرمز المميز أو كان قريبًا من انتهاء الصلاحية، تستخدم APIM رمز التحديث المميز لإحضار رمز وصول جديد ورمز تحديث مميز جديد من موفر الهوية المكون. إذا انتهت صلاحية الرمز المميز للتحديث، يتم طرح خطأ، ويجب إعادة تفويض الاتصال قبل أن يعمل.

ماذا يحدث إذا انتهت صلاحية سر العميل في موفر الهوية؟

في وقت التشغيل، لا يمكن لإدارة واجهة برمجة التطبيقات إحضار رموز مميزة جديدة، ويحدث خطأ.

  • إذا كان الاتصال من نوع رمز التخويل، يجب تحديث سر العميل على مستوى موفر بيانات الاعتماد.

  • إذا كان الاتصال من نوع بيانات اعتماد العميل، يجب تحديث سر العميل على مستوى الاتصال.

هل هذه الميزة مدعومة باستخدام إدارة واجهة برمجة التطبيقات التي تعمل داخل VNet؟

نعم، طالما تم تمكين الاتصال الصادر على المنفذ 443 إلى علامة خدمة Azure الاتصال ors. لمزيد من المعلومات، راجع مرجع تكوين الشبكة الظاهرية.

ماذا يحدث عند حذف موفر بيانات الاعتماد؟

يتم أيضا حذف جميع الاتصالات الأساسية ونهج الوصول.

هل يتم تخزين رموز الوصول المميزة مؤقتًا بواسطة APIM؟

في مستويات الخدمة الكلاسيكية وv2، يتم تخزين الرمز المميز للوصول مؤقتا بواسطة مثيل APIM حتى 3 دقائق قبل وقت انتهاء صلاحية الرمز المميز. إذا كان الرمز المميز للوصول على بعد أقل من 3 دقائق من انتهاء الصلاحية، فسيكون الوقت المخزن مؤقتا حتى تنتهي صلاحية الرمز المميز للوصول.

لا يتم تخزين رموز الوصول المميزة مؤقتا في مستوى الاستهلاك.

المحتوى ذو الصلة