ما هي المصادقة؟

  • مقالة
  • قراءة خلال 7 دقائق

تحذير

يخص هذا المحتوى نقطة النهاية الأقدم لإصدار Microsoft Azure Active Directory v1.0. استخدم النظام الأساسي للهويات في Microsoft للمشاريع الجديدة.

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

التفويض هو فعل منح إذن أمان أساسي مصدق عليه للقيام بشيء ما. إنه يحدد البيانات التي يُسمح لك بالوصول إليها وما يمكنك فعله بها. يتم اختصار التخويل في بعض الأحيان إلى AuthZ.

يعملAAD (دليل Azure النشط) للمطورين (الإصدار 1.0) (Azure AD) على تبسيط المصادقة لمطوري التطبيقات من خلال توفير الهوية كخدمة، مع دعم البروتوكولات القياسية في الصناعة مثل OAuth 2.0 و OpenID Connect، بالإضافة إلى مكتبات مفتوحة المصدر لمختلف الأنظمة الأساسية لمساعدتك على بدء البرمجة بسرعة.

هناك حالتان للاستخدام الأساسي في نموذج برمجة AAD (دليل Azure النشط):

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

أساسيات المصادقة في AAD (دليل Azure النشط)

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

Overview of sign-on to web application

إليك ما تحتاج إلى معرفته حول المكونات المختلفة المعروضة في الرسم التخطيطي:

  • AAD (دليل Azure النشط) هو موفر الهوية. موفر الهوية مسؤولة عن التحقق من هوية المستخدمين والتطبيقات الموجودة في دليل المؤسسة، وإصدار رموز الأمان عند المصادقة الناجحة لهؤلاء المستخدمين والتطبيقات.
  • يجب تسجيل التطبيق الذي يريد الاستعانة بمصادر خارجية لمصادقة Azure AD في AAD (دليل Azure النشط) (Azure AD). يسجل Azure AD التطبيق في الدليل ويحدده بشكل فريد.
  • يمكن للمطورين استخدام مكتبات مصادقة Azure AD مفتوحة المصدر لتسهيل المصادقة من خلال معالجة تفاصيل البروتوكول لك. لمزيد من المعلومات، راجع مكتبات مصادقة نظام تعريف Microsoft الأساسي الإصدار 2.0 ومكتبات المصادقة الإصدار 1.0.
  • بمجرد مصادقة مستخدم، يجب أن يتحقق التطبيق من صحة رمز أمان المستخدم للتأكد من نجاح المصادقة. يمكنك العثور على التشغيل السريع والبرنامج التعليمي وعينات التعليمة البرمجية بمجموعة متنوعة من اللغات والأطر التي تظهر ما يجب أن يفعله التطبيق.
    • لإنشاء تطبيق بسرعة وإضافة وظائف مثل الحصول على الرموز المميزة وتحديث الرموز المميزة وتوقيع الدخول إلى مستخدم وعرض بعض معلومات المستخدم والمزيد، راجع قسم التشغيل السريع في الوثائق.
    • للحصول على إجراءات متعمقة تستند إلى السيناريو لمهام المطور الأول مثل الحصول على رموز الوصول واستخدامها في المكالمات إلى Microsoft Graph API وواجهة برمجة التطبيقات الأخرى، وتنفيذ تسجيل الدخول مع Microsoft باستخدام تطبيق تقليدي يستند إلى مستعرض الويب باستخدام اتصال OpenID، وأكثر من ذلك، راجع قسم البرنامج التعليمي في الوثائق.
    • لتنزيل نماذج التعليمات البرمجية، انتقل إلى GitHub.
  • يتم تحديد تدفق الطلبات والاستجابات لعملية المصادقة بواسطة بروتوكول المصادقة الذي استخدمته، مثل OAuth 2.0 أو اتصال OpenID أو WS-Federation أو SAML 2.0. لمزيد من المعلومات حول البروتوكولات، راجع قسم المفاهيم > بروتوكول المصادقة في الوثائق.

في سيناريو المثال أعلاه، يمكنك تصنيف التطبيقات وفقا لهذين الدورين:

  • التطبيقات التي تحتاج إلى الوصول إلى الموارد بأمان
  • التطبيقات التي تلعب دور المورد نفسه

كيف يصدر كل تدفق الرموز المميزة والتعليمات البرمجية

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

تدفق يتطلب id_token الرمز المميز للوصول تحديث الرمز المميز تعليم التفويض البرمجي
تدفق تعليمات التفويض البرمجية x x x x
التدفق الضمني x x
تدفق OIDC المختلط x x
تحديث استرداد الرمز المميز تحديث الرمز المميز x x x
نيابة عن التدفق الرمز المميز للوصول x x x
بيانات اعتماد العميل x (التطبيق فقط)

الرموز المميزة الصادرة عبر الوضع الضمني لها حد طول بسبب تمريرها مرة أخرى إلى المتصفح عبر عنوان URL (أينresponse_modeهوqueryأوfragment). بعض المستعرضات لها حد على حجم عنوان URL الذي يمكن وضعه في شريط المستعرض وتفشل عندما يكون طويلا جدا. وبالتالي، هذه الرموز لا تملك مطالبات groups أو wids.

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

نموذج التطبيق

يمثل Azure AD التطبيقات التي تتبع نموذجا معينا تم تصميمه لتحقيق وظيفتين رئيسيتين:

  • تحديد التطبيق وفقا لبروتوكولات المصادقة التي يدعمها - يتضمن ذلك تعداد جميع المعرفات وعناوين URL والأسرار والمعلومات ذات الصلة المطلوبة في وقت المصادقة. هنا، AAD (دليل Azure النشط):

    • يحتفظ بكافة البيانات المطلوبة لدعم المصادقة في وقت التشغيل.
    • يحتفظ بجميع البيانات لتحديد الموارد التي قد يحتاج التطبيق إلى الوصول إليها وما إذا كان يجب تلبية طلب معين وتحت أي ظروف.
    • يوفر البنية التحتية لتنفيذ توفير التطبيق داخل مستأجر مطور التطبيق ولأي مستأجر آخر في Azure AD.

  • التعامل مع موافقة المستخدم أثناء وقت طلب الرمز المميز وتسهيل التوفير الديناميكي للتطبيقات عبر المستأجرين - هنا، Azure AD:

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

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

يظهر الرسم التخطيطي التالي توفيرا مبسطا لخدمات Azure AD التي تستند إلى الموافقة. في ذلك، يوجد مستأجران (A وB)، حيث يمتلك المستأجر A التطبيق، والمستأجر B يقوم بإعادة إنشاء التطبيق عبر كيان الخدمة.

Simplified provisioning flow driven by consent

في تدفق توفير الخدمة هذا:

  1. يحاول مستخدم من المستأجر B تسجيل الدخول باستخدام التطبيق، وتطلب نقطة نهاية التخويل رمزا مميزا للتطبيق.
  2. يتم الحصول على بيانات اعتماد المستخدم والتحقق من المصادقة
  3. تتم مطالبة المستخدم بتقديم موافقة للتطبيق للوصول إلى المستأجر B
  4. Azure AD يستخدم عنصر التطبيق في المستأجر A كمخطط لإنشاء خدمة رئيسية في المستأجر B
  5. يتلقى المستخدم الرمز المميز المطلوب

يمكنك تكرار هذه العملية عدة مرات كما تريد للمستأجرين الآخرين (C وD وهكذا). يحتفظ المستأجر A بمخطط التطبيق (عنصر التطبيق). يحتفظ مستخدمو ومسؤولو جميع المستأجرين الآخرين الذين يتم منحهم الموافقة على التطبيق بالتحكم في ما يسمح للتطبيق بالقيام به من خلال العنصر الأساسي للخدمة المقابلة في كل مستأجر. للحصول على مزيدٍ من المعلومات، راجع التطبيقات والكيانات الأساسية للخدمة في النظام الأساسي للهويات في Microsoft.

المطالبات في رموز Azure AD المميزة

تحتوي الرموز المميزة (رموز الوصول والرمز المميز للتعرف) الصادرة عن Azure AD على مطالبات أو تأكيدات بمعلومات حول الموضوع الذي تمت مصادقته. يمكن للتطبيقات استخدام المطالبات لمختلف المهام، بما في ذلك:

  • التحقق من صحة الرمز المميز
  • تحديد مستأجر دليل الموضوع
  • عرض معلومات المستخدم
  • تحديد تخويل الموضوع

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

يتوفر وصف موجز لكل نوع من أنواع المطالبات الصادرة عن Azure AD في الجدول أدناه. للحصول على مزيد من المعلومات التفصيلية، راجع رموز الوصول المميزةورموز الهوية المميزة الصادرة عن Azure AD.

المطالبة الوصف
معرّف التطبيق تعريف التطبيق الذي يستخدم الرمز المميز.
الجمهور تعريف مورد المستلم الذي تم تخصيص الرمز المميز له.
مرجع فئة سياق مصادقة التطبيق يشير إلى كيفية مصادقة العميل (عميل عام مقابل عميل سري).
لحظة المصادقة تسجيل التاريخ والوقت عند حدوث المصادقة.
أسلوب المصادقة يشير إلى كيفية مصادقة موضوع الرمز المميز (كلمة المرور والشهادة وما إلى ذلك).
الاسم الأول يوفر اسم المستخدم المحدد كما هو محدد في Azure AD.
المجموعات يحتوي على معرّفات عناصر مجموعات Azure AD التي يكون المستخدم عضوًا فيها.
موفر الهوية تسجيل موفر الهوية الذي قام بمصادقة موضوع الرمز المميز.
صدر في يسجل الوقت الذي تم فيه إصدار الرمز المميز، وغالبًا ما يستخدم لتحديث الرمز المميز.
مُصدر الشهادة تعرف خدمة security token التي تنبعث منها الرمز المميز وكذلك المستأجر Azure AD.
اسم العائلة يوفر اسم عائلة المستخدم كما هو محدد في Azure AD.
الاسم يوفر قيمة قابلة للقراءة البشرية التي تعرف موضوع الرمز المميز.
معرف الكائن يحتوي على معرف فريد وغير قابل للتغيير للموضوع في Azure AD.
الأدوار يحتوي على أسماء مألوفة من أدوار تطبيقات AAD (دليل Azure النشط) التي تم منحها للمستخدم.
النطاق يشير إلى الأذونات الممنوحة إلى تطبيق العميل.
الموضوع يشير إلى الأصل الذي يؤكد الرمز المميز المعلومات حوله.
معرف المستأجر يحتوي على معرف فريد ثابت لمستأجر الدليل الذي أصدر الرمز المميز.
مدة بقاء الرمز المميز يحدد الفاصل الزمني الذي يكون الرمز المميز صالحًا خلاله.
اسم المستخدم الأساسي يحتوي على اسم المستخدم الأساسي للموضوع.
إصدار يحتوي على رقم إصدار الرمز المميز.

الخطوات التالية