نمط الهوية الموحدة

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

السياق والمشكلة

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

• يتسبب في تجربة مستخدم منفصلة. غالبا ما ينسى المستخدمون بيانات اعتماد تسجيل الدخول عندما يكون لديهم العديد من البيانات المختلفة.

• عرض الثغرات الأمنية. يجب، عند مغادرة المستخدم الشركة، إلغاء توفير الحساب على الفور. من السهل التغاضي عن ذلك في المؤسسات الكبيرة.

• تعقيد إدارة المستخدم. يجب على المسؤولين إدارة بيانات الاعتماد لجميع المستخدمين، وتنفيذ مهام إضافية مثل إرسال رسائل تذكير بكلمة مرور.

يفضل المستخدمون عادة استخدام نفس بيانات الاعتماد لجميع هذه التطبيقات.

حل

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

يتضمن موفرو الهوية الموثوق بهم دلائل الشركات أو خدمات الاتحاد المحلية أو خدمات الرموز المميزة للأمان الأخرى (STS) التي يوفرها شركاء العمل أو موفرو الهوية الاجتماعية الذين يمكنهم المصادقة على مستخدمين يمتلكون، على سبيل المثال، حساب Microsoft أو Google أو Yahoo! أو Facebook.

يوضح الرسم التوضيحي نمط «الهوية الموحدة» عندما يحتاج تطبيق العميل إلى الوصول إلى خدمة تتطلب المصادقة. يتم تنفيذ المصادقة بواسطة IdP يعمل بالتوافق مع STS. يصدر IdP رموز الأمان المميزة التي توفر معلومات حول المستخدم المصدق عليه. تتضمن هذه المعلومات، المشار إليها باسم المطالبات، هوية المستخدم وقد تتضمن أيضا معلومات أخرى مثل عضوية الدور وحقوق وصول متعددة المستويات.

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

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

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

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

المسائل والاعتبارات

يوصى بمراعاة ما يلي عند تصميم التطبيقات التي تنفذ المصادقة الموحدة:

• يمكن أن تكون المصادقة نقطة فشل واحدة. إذا قمت بنشر التطبيق على مراكز بيانات متعددة، فيوصى بمراعاة نشر آلية إدارة الهوية لديك على مراكز البيانات نفسها للحفاظ على موثوقية وتوافر التطبيق.

• تسمح أدوات المصادقة بإمكانية تكوين التحكم في الوصول استنادا إلى مطالبات الدور المضمنة في رمز المصادقة المميز. يُشار إلى هذا غالبا باسم التحكم في الوصول استنادا إلى الدور (RBAC)، ويمكن أن يسمح بمستوى أكثر دقة من التحكم في الوصول إلى الميزات والموارد.

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

• إذا كان هناك أكثر من موفر هوية واحد تم تكوينه ل STS، يجب أن تحدد STS موفر الهوية الذي يجب إعادة توجيه المستخدم إليه للمصادقة. تسمى هذه العملية اكتشاف النطاق الرئيسي. قد يتمكن STS من تنفيذ ذلك تلقائيا استنادا إلى عنوان البريد الإلكتروني أو اسم المستخدم الذي يوفره المستخدم أو مجال فرعي للتطبيق الذي يصل إليه المستخدم، أو نطاق عنوان IP الخاص بالمستخدم، أو على محتويات ملف تعريف الارتباط المخزن في مستعرض المستخدم. على سبيل المثال، إذا أدخل المستخدم عنوان بريد إلكتروني في مجال Microsoft مثل user@live.com، فسيوجه STS المستخدم إلى صفحة تسجيل الدخول إلى حساب Microsoft. يمكن ل STS، في الزيارات اللاحقة، استخدام ملف تعريف الارتباط للإشارة إلى أن آخر تسجيل دخول كان باستخدام حساب Microsoft. إذا لم يتمكن الاكتشاف التلقائي من تحديد نطاق التصديق الأولي، فسيعرض STS صفحة اكتشاف نطاق التصديق الأولي التي تسرد موفري الهوية الموثوق بهم، ويجب على المستخدم تحديد موفر الهوية الذي يريد استخدامه.

موعد استخدام النمط

هذا النمط مفيد لسيناريوهات مثل:

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

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

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

قد لا يكون هذا النمط مفيدا في الحالات التالية:

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

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

تصميم حمل العمل

يجب على المهندس المعماري تقييم كيفية استخدام نمط الهوية الموحدة في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:

كما هو الحال مع أي قرار تصميم، ضع في اعتبارك أي مفاضلات ضد أهداف الركائز الأخرى التي يمكن إدخالها مع هذا النمط.

مثال

تستضيف المؤسسة برنامجا متعدد المستأجرين كتطبيق خدمة (SaaS) في Microsoft Azure. يتضمن التطبيق موقع ويب يمكن للمستأجرين استخدامه لإدارة التطبيق لمستخدميهم. يسمح التطبيق للمستأجرين بالوصول إلى موقع الويب باستخدام هوية موحدة يتم إنشاؤها بواسطة خدمات الأمان المشترك لـ Active Directory (AD FS) عند مصادقة مستخدم بواسطة Active Directory الخاص بهذه المؤسسة.

يعرض الرسم التوضيحي كيفية مصادقة المستأجرين باستخدام موفر الهوية (الخطوة 1)، في هذه الحالة AD FS. بعد نجاح مصادقة المستأجر، يُصدر AD FS رمزا مميزا. يعيد مستعرض العميل توجيه هذا الرمز المميز إلى موفر اتحاد تطبيق SaaS الذي يثق في الرموز المميزة الصادرة عن AD FS للمستأجر من أجل الحصول على رمز مميز صالح لموفر اتحاد SaaS (الخطوة 2). يجري موفر اتحاد SaaS، إذا لزم الأمر، تحويل على المطالبات في الرمز المميز إلى مطالبات يتعرف عليها التطبيق (الخطوة 3) قبل إرجاع الرمز المميز الجديد إلى مستعرض العميل. يثق التطبيق في الرموز المميزة الصادرة عن موفر اتحاد SaaS ويستخدم المطالبات في الرمز المميز لتطبيق قواعد التخويل (الخطوة 4).

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

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

• معرِّف Microsoft Entra
• خدمات مجال Active Directory
• خدمات الأمان المشترك لـ Active Directory
• التطبيقات متعددة المستأجرين في Azure

الموارد ذات الصلة

• إدارة الهوية للتطبيقات متعددة المستأجرين في Microsoft Azure
• نمط حارس البوابة
• نمط تكوين حمل عمل Edge
• نمط حساب دمج الموارد
• نمط إلغاء تحميل البوابة