مشاركة عبر

الاعتبارات المعمارية للهوية في حل متعدد المستأجرين

  • مقالة

الهوية هي جانب مهم من أي حل متعدد المستأجرين. مكونات الهوية للتطبيق الخاص بك هي المسؤولة عن كل مما يلي:

  • التحقق من هوية المستخدم (المصادقة).
  • فرض أذونات المستخدم ضمن نطاق المستأجر (التخويل).

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

تنبيه

عادة ما يتم توفير خدمات المصادقة والتخويل، ضمن تطبيقات متعددة المستأجرين وSaaS، من قبل موفر هوية تابع لجهة خارجية (IdP). عادة ما يكون موفر الهوية جزءا لا يتجزأ من النظام الأساسي للهوية كخدمة (IDaaS).

يعد بناء موفر هوية خاص بك معقدا ومكلفا ويصعب بناءه بشكل آمن. بناء موفر الهوية الخاص بك هو مضاد للانترنيترن. لا نوصي بذلك.

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

  • هل سيتم استخدام هويات المستخدم أو حمل العمل للوصول إلى تطبيق واحد أو تطبيقات متعددة داخل عائلة منتج؟ على سبيل المثال، قد تحتوي عائلة منتجات البيع بالتجزئة على كل من تطبيق نقطة البيع وتطبيق إدارة المخزون، والتي تشترك في نفس حل الهوية.
  • هل تخطط لتنفيذ المصادقة والتخويل الحديثين، مثل OAuth2 وOpenID Connect؟
  • هل يوفر الحل الخاص بك المصادقة فقط للتطبيقات المستندة إلى واجهة المستخدم الخاصة بك؟ أو، هل توفر أيضا وصول واجهة برمجة التطبيقات إلى المستأجرين والأطراف الثالثة؟
  • هل سيحتاج المستأجرون إلى الاتحاد مع موفر الهوية الخاص بهم، وسيتعين دعم العديد من موفري الهوية المختلفين لكل مستأجر؟ على سبيل المثال، قد يكون لديك مستأجرون لديهم معرف Microsoft Entra و Auth0 و خدمات الأمان المشترك لـ Active Directory (ADFS)، حيث يرغب كل واحد في الاتحاد مع الحل الخاص بك. تحتاج أيضا إلى فهم بروتوكولات الاتحاد لمستأجريك IdPs التي ستدعمها، لأن البروتوكولات تؤثر على متطلبات IdP الخاص بك.
  • هل هناك متطلبات امتثال محددة يحتاجون إلى تلبيتها، مثل القانون العام لحماية البيانات؟
  • هل يطلب المستأجرون من معلومات هويتهم أن تكون موجودة داخل منطقة جغرافية معينة؟
  • هل يحتاج مستخدمو الحل الخاص بك إلى الوصول إلى البيانات من مستأجر واحد أو من عدة مستأجرين داخل التطبيق الخاص بك؟ هل يحتاجون إلى القدرة على التبديل بسرعة بين المستأجرين أو عرض المعلومات الموحدة من عدة مستأجرين؟ على سبيل المثال، يمكن للمستخدمين الذين سجلوا الدخول إلى مدخل Microsoft Azure التبديل بسهولة بين دلائل معرف Microsoft Entra المختلفة والاشتراكات التي لديهم حق الوصول إليها.

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

دليل الهوية

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

عند تصميم نظام هوية للحل متعدد المستأجرين، تحتاج إلى مراعاة أي من أنواع IdP التالية التي قد يحتاجها المستأجرون والعملاء:

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

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

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

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

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

تنبيه

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

ضع في اعتبارك الخيارات التالية لتخزين معلومات الهوية:

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

تحديد عدد الهويات لمستخدم

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

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

منح المستخدمين حق الوصول إلى بيانات المستأجر

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

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

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

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

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

عملية تسجيل المستخدم للهويات المحلية أو الهويات الاجتماعية

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

  • ما هي مصادر الهوية التي يسمح للمستخدمين بالتسجيل منها؟ على سبيل المثال، هل يمكن للمستخدم إنشاء هوية محلية واستخدام موفر هوية اجتماعية أيضا؟
  • إذا تم السماح بالهويات المحلية فقط، هل سيتم السماح بمجالات بريد إلكتروني محددة فقط؟ على سبيل المثال، هل يمكن للمستأجر تحديد السماح فقط للمستخدمين الذين لديهم عنوان بريد إلكتروني @contoso.com بالتسجيل؟
  • ما هو اسم المستخدم الأساسي (UPN) الذي يجب استخدامه لتعريف كل هوية محلية بشكل فريد أثناء عملية تسجيل الدخول؟ على سبيل المثال، عنوان البريد الإلكتروني واسم المستخدم ورقم الهاتف ورقم بطاقة المكافآت كلها خيارات شائعة ل UPNs. ومع ذلك، يمكن أن تتغير UPNs بمرور الوقت. عند الإشارة إلى الهوية في قواعد التخويل الخاصة بالتطبيق أو سجلات التدقيق، من الجيد استخدام المعرف الفريد الأساسي غير القابل للتغيير للهوية. يوفر معرف Microsoft Entra معرف كائن (OID)، وهو معرف غير قابل للتغيير.
  • هل سيطلب من المستخدم التحقق من UPN؟ على سبيل المثال، إذا تم استخدام عنوان البريد الإلكتروني للمستخدم أو رقم هاتفه ك UPN، فكيف ستتحقق من دقة المعلومات؟
  • هل يحتاج مسؤولو المستأجر إلى الموافقة على عمليات التسجيل؟
  • هل يحتاج المستأجرون إلى تجربة تسجيل خاصة المستأجر أو عنوان URL؟ على سبيل المثال، هل يتطلب المستأجرون تجربة تسجيل ذات علامة تجارية عند تسجيل المستخدمين؟ هل يتطلب المستأجرون القدرة على اعتراض طلب تسجيل وإجراء تحقق إضافي قبل أن يستمر؟

وصول المستأجر لمستخدمي التسجيل الذاتي

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

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

إدارة دورة حياة الحساب التلقائي

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

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

عملية مصادقة المستخدم

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

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

هويات حمل العمل.

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

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

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

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

الاتحاد مع موفر هوية لتسجيل الدخول الأحادي (SSO)

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

يعد الاتحاد مهما بشكل خاص عندما يرغب بعض المستأجرين في تحديد نهج الهوية الخاصة بهم، أو لتمكين تجارب تسجيل الدخول الأحادي (SSO).

إذا كنت تتوقع أن يصادق المستأجرون على الحل الخاص بك، فيجب مراعاة الأسئلة التالية:

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

نماذج التخويل

حدد نموذج التخويل الأكثر منطقية للحل الخاص بك. نهجان شائعان للتخويل هما:

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

هذه النماذج مميزة، ويؤثر النهج الذي تحدده على تنفيذك وتعقيد نهج التخويل التي يمكنك تنفيذها.

الاستحقاقات والترخيص

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

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

مقياس الهوية وحجم المصادقة

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

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

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكتاب الرئيسيون:

مساهمون آخرون:

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

مراجعة الأساليب المعمارية للهوية في الحلول متعددة المستأجرين.