الهوية وإدارة الوصول للعملاء 101: المصادقة، الهوية، وتسجيل الدخول الموحد

الخلفية#

بدأت في بناء Logto لأنني لاحظت أن إدارة الهوية والوصول (IAM) أصبحت معقدة ومتشعبة بمرور الوقت. أصبح مفهوم IAM كبيرًا بما يكفي لظهور مفاهيم جديدة مثل WIAM (IAM للقوى العاملة) وCIAM (IAM للعملاء).

بالرغم من أن WIAM وCIAM يشتركان في نفس الأساس، إلا أن لهما استخدامات مختلفة: WIAM يُستخدم بشكل عام للمستخدمين الداخليين، بينما CIAM يُستخدم للعملاء الخارجيين. بعض الأمثلة:

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

بدأ Logto مع CIAM لأسباب عديدة (سنناقش هذا في مقال آخر). خلال التطوير، أدركنا أن بناء فهم موحد في جميع أنحاء الفريق سيكون مفيدًا قبل أخذ منتجنا إلى المستوى التالي. نأمل أن يساعدك هذا أيضًا في فهم أفضل للمناظر الطبيعية لـIAM.

لنبدأ!

أساسيات CIAM#

في هذه المقالة، سنركز على المفاهيم الأساسية لـCIAM والمشاكل التي قد نواجهها خلال عملية المصادقة أو بعدها. سنناقش أيضًا تسجيل الدخول الموحد (SSO) والسيناريوهات المتعلقة به.

المصادقة والتفويض#

💡 تم تعريف المصادقة في بادئ الأمر بأنها "من أنت؟". ومع ذلك، عند مناقشة الهويات الرقمية، من الأدق توضيح المصادقة بـ "إثبات ملكية الهوية". (الشكر لـ Calm-Card-2424)

إذا اكتشفت شيئًا لا يندرج ضمن أي من هاتين الفئتين، فمن المرجح أنه ليس ضروريًا لأعمال الهوية.

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

الهوية والمستأجر#

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

بعبارة أخرى، الهدف الرئيسي من المصادقة هو الحصول على هوية.

المستأجر هو مجموعة من الهويات:

عند مناقشة "متعدد المستأجرين"، نشير إلى عدة نماذج من Logto تكون معزولة الهوية عن بعضها البعض. بعبارة أخرى، عدة نماذج من Logto.

لاحظ أنه يحتوي على نظامي هوية معزولين، أي أنك لا تستطيع استخدام هوية المستأجر 1 في المستأجر 2، حتى لنفس المعرف (البريد الإلكتروني، الهاتف، إلخ). هو مثل عضوية Costco الخاصة بك ليست صالحة في Whole Foods.

التطبيق والمستأجر#

مثل الهوية، ينتمي التطبيق أيضًا إلى مستأجر. هناك عدة أشياء يجب تذكرها:

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

مزود الهوية (IdP) ومزود الخدمة (SP)#

الفرق بين هذين المزودين معقد ولكنه مهم.

• مزود الهوية هو خدمة تقدم المصادقة (AuthN) وتصدر الهويات.

يمكنك العثور على تفسيرات مختلفة لمزود الخدمة من Google، على الرغم من أنها قد لا تكون مرضية. في رأيي، مزود الخدمة هو مفهوم نسبي:

• مزود الخدمة (أو الحليف في OIDC) هو خدمة أو عميل يبدأ المصادقة (AuthN) ويطلب النتيجة من مزودي الهوية.

مسابقة#

فكر في سيناريو نموذجي لتسجيل الدخول الاجتماعي:

❓ كم عدد موفري الخدمة وموفري الهوية في هذا الرسم؟

الإجابة

كلاهما اثنين. تطبيق iOS هو موفر خدمة لـLogto، بينما Logto هو مزود هوية. Logto هو أيضًا موفر خدمة لـGitHub، بينما GitHub هو مزود هوية. ولذلك، Logto هو مزود خدمة وأيضًا مزود هوية.

دراسة حالة: شركة حلول تقنية#

أنت رئيس التكنولوجيا التنفيذية لشركة حلول تقنية، لديك أكثر من 100 شريك عمل وقد قدمت أكثر من 300 مشروع.

• كل مشروع إما تطبيق ويب أو تطبيق موبايل مع خدمة خلفية.
• لكل شريك عمل، تريد إعادة صياغة نظام المستخدم لتقديم SSO عبر مشاريعه.

❓ كيف يمكن لـLogto (أو منتج CIAM) المساعدة؟

الإجابة

أنشئ نموذج Logto لكل شريك عمل. يحتفظ كل شريك بمستأجر. المشاريع تُربط بـ"التطبيقات" في Logto.

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

ماذا نتحدث عن عندما نتحدث عن SSO#

وجدنا أن مصطلح "SSO" غالبًا ما يسبب الارتباك. نعتبر تسجيل الدخول الموحد (SSO) سلوكًا، وليس مفهومًا تجاريًا. ولذلك، لا يوازي SSO مصطلح "SSO في WIAM".

عندما نقول "يحتاج إلى SSO"، يمكن أن يشير إلى إحدى الحالات التالية:

حالة SSO 1#

👉🏽 في شركة كبيرة، يستخدم الموظفون نفس بيانات الاعتماد لتسجيل الدخول إلى جميع الموارد المرخصة من الشركة (مثل البريد الإلكتروني، وخدمة الرسائل الفورية، والخدمات السحابية).

إنها حالة WIAM النموذجية. في هذه الحالة، يشارك مخصص واحد فقط لمزود الهوية. لا نهتم الآن.

حالة SSO 2#

👉🏽 يستخدم المستخدمون النهائيون نفس بيانات الاعتماد لتسجيل الدخول إلى جميع الخدمات التي طورتها نفس الشركة (مثل مجموعة GSuite).

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

على الرغم من ذلك، تظل Logto مصدر الحقيقة الوحيد للهوية، ببساطة "تستعير" الهويات من مقدمي الخدمة الآخرين. في هذه الحالة، تعمل Logto كمزود هوية (لتطبيقات GSuite) وكموفر خدمة (لمزودي الهوية الخارجيين).

حالة SSO 3#

👉🏽 يمكن للمستخدمين النهائيين استخدام موفر هوية محدد فقط داخل نطاق البريد الإلكتروني المخصص لإكمال المصادقة. على سبيل المثال، تسجيل الدخول إلى Figma مع Google Workspace.

هذا هو حالة الاستخدام الأكثر شيوعًا لـSSO في CIAM. لنلقِ نظرة أقرب.

إذا أردنا تسجيل الدخول إلى Figma باستخدام البريد الإلكتروني الخاص بنا @silverhand.io، يمكننا استخدام إما تسجيل الدخول الاجتماعي أو SSO. الأشكال أدناه توضح الفرق بين الاثنين:

بكلمات:

• بعد تسجيل الدخول الاجتماعي، يمكن للمستخدمين تعيين كلمة مرور أو تغيير عنوان البريد الإلكتروني في Figma
• بعد SSO، لا يمكن للمستخدمين تعيين كلمة مرور أو تغيير أي معلومات شخصية بما في ذلك عنوان البريد الإلكتروني، لأن الهويات الخاصة بهم تدار بواسطة Google Workspace

في هذه الحالة، Logto هو مزود الهوية ومزود الخدمة. يبدو أن SSO أكثر تعقيدًا من عملية تسجيل الدخول العادية. ما هي الفوائد لمالك الهوية؟

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

🤔 أذكى منك قد لاحظت أن هذا في الواقع حالة SSO 1 من منظور SaaS.

حان الوقت لمناقشة "X" في رسم SSO. هذا يمثل عملية الاتصال بـFigma لنطاق البريد الإلكتروني موفر الهوية المحدد. لكن، كيف يعمل؟

تعيين SSO#

بما أن الطلب غالبًا يأتي من عملاء الشركات، نشير إلى عملية "حالة SSO 3" من القسم السابق باسم "SSO المؤسسات" لتوضيح.

يمكننا بسهولة ابتكار حل بسيط: إنشاء تعيين بين نطاقات البريد الإلكتروني وطرق SSO، ثم تحديثه يدويًا.

تعتبر عملية "X" واضحة الآن:

🔍 العثور على طريقة SSO المؤسسية المعينة لنطاق البريد الإلكتروني المحدد

لذلك، إذا قمت بتكوين silverhand.io كنطاق بريد إلكتروني صالح يتصل بعنوان URL لـSSO في Google Workspace، سيتم توجيه المستخدمين الذين يحاولون تسجيل الدخول باستخدام بريد @silverhand.io الإلكتروني إلى صفحة تسجيل الدخول في Google Workspace المقابلة لهم، بدلًا من معالجتهم في المكان.

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

1. ماذا لو كان هناك مئات أو الآلاف من عملاء SSO للمؤسسات؟
2. ما العلاقة بين "المستخدمين العاديين" و "مستخدمي SSO للمؤسسات"؟
3. هل ينبغي عزل البيانات بين عملاء SSO للمؤسسات المختلفة؟
4. هل هناك حاجة لتوفير لوحة بيانات لمشرفي SSO للمؤسسات لعرض المستخدمين النشطين، وسجلات التدقيق، إلخ؟
5. كيف يمكن تعطيل الحسابات بشكل تلقائي عند إزالة المستخدم من موفر الهوية الخاص بـSSO للمؤسسات؟

والمزيد. بما أن جميع عملاء SSO للمؤسسات تقريبًا يعتمدون على نطاق البريد الإلكتروني، يمكننا بسرعة إيجاد حل أفضل:

• إذا تمكن المستخدم من إثبات ملكية هذا النطاق، يمكنه إعداد SSO للمؤسسات لذلك النطاق بطريقة الخدمة الذاتية.

هذا الحل يعالج السؤالين الأول والثاني:

1. ماذا لو كان هناك مئات أو الآلاف من عملاء SSO للمؤسسات؟

• يمكنهم تكوين SSO للمؤسسات بطريقة الخدمة الذاتية.

2. ما العلاقة بين "المستخدمين العاديين" و "مستخدمي SSO للمؤسسات"؟

• نقوم بفتح جميع طرق تسجيل الدخول الممكنة للمستخدمين العاديين باستثناء SSO للمؤسسات؛ بينما نقصر طريقة تسجيل الدخول على SSO للمؤسسات فقط على المستخدمين الذين يحاولون تسجيل الدخول باستخدام النطاقات المكونة لهم.

بالنسبة للسؤال الثالث:

3. هل ينبغي عزل البيانات بين عملاء SSO للمؤسسات المختلفة؟

• نعم ولا. حان الوقت لتقديم التنظيم.

التنظيم#

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

ولكن، متطلبات العملاء غالبًا ما تكون أكثر من مجرد SSO للمؤسسات؛ مثلا، الأسئلة 4 و5 في القسم السابق. على مر السنين، تم تطوير نموذج ناضج من قبل شركات SaaS البارزة لمعالجة هذه الأنواع من المشاكل: التنظيمات.

قواعد التنظيم

1. التنظيم هو مجموعة من الهويات، وعادة ما تكون أصغر من المستأجر.
2. ترتبط جميع التنظيمات بمستأجر.

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

في هذه المقالة، سنستخدم مصطلح "التنظيم" للاتساق.

في Notion، يمكنك إنشاء والانضمام إلى مساحات عمل متعددة (أي تنظيمات) بنفس عنوان البريد الإلكتروني والتبديل بينها بسهولة.

بالنسبة لـSlack، يبدو أنها نفسها، لكننا نشك في أنها تستخدم هويات مختلفة في الخلفية حيث نحتاج إلى إنشاء حساب جديد لكل مساحة عمل.

Notion لديه متوفر "خطة شخصية"، والتي هي عادة تنظيم تحت الغطاء، مع المستخدم الوحيد (أنت) بداخله. لا نعرف التنفيذ الدقيق لـNotion، ولكن هذا الشرح معقول ويمكن تحقيقه لنموجنا.

كل تنظيم لديه أيضًا معرف، غالبًا ما يشار إليه باسم "نطاق التنظيم".

مسابقة#

❓ هل يمكن أن يتم ربط التطبيق مع التنظيم؟

الإجابة

نعم نعم. كما ناقشنا في البداية، يمكن أن يكون للتطبيق هوية. هل يمكنك توضيح سيناريو عمل لذلك؟

الأسئلة المتبقية#

3. هل ينبغي عزل البيانات بين عملاء SSO للمؤسسات المختلفة؟

• نعم: عزل بيانات الأعمال، مثل الرسائل والوثائق، على مستوى التنظيم.
• لا: حافظ على استقلالية الهويات، حيث لا تحتاج لأن تكون مرتبطة بتنظيم.
• لاحظ أن هناك ثلاث كيانات متميزة متورطة هنا: الهويات، التنظيمات، وتكوينات SSO للمؤسسات؛ مما زاد من التعقيد بشكل لافت. السؤال نفسه ليس دقيقًا بما يكفي.

4. هل هناك حاجة لتوفير لوحة بيانات لمشرفي SSO للمؤسسات لعرض المستخدمين النشطين، وسجلات التدقيق، إلخ؟

5. كيف يمكن تعطيل الحسابات بشكل تلقائي عند إزالة المستخدم من موفر الهوية الخاص بـSSO للمؤسسات؟

• هذه المطالبات أكثر توجهًا نحو الأعمال ويمكن تنفيذها على مستوى التنظيم. سنتركها مفتوحة هنا.

خاتمة#

لقد قدمنا مفاهيم عدة: المصادقة (AuthN)، التفويض (AuthZ)، الهوية، المستأجر، التطبيق، مزود الهوية (IdP)، مزود الخدمة (SP)، تسجيل الدخول الموحد (SSO)، وSSO للمؤسسات (التنظيم). قد يستغرق فهمهم جميعًا بعض الوقت.

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

• كيف يمكننا تحديد الأذونات لمستخدم والتحقق منها؟
• ما النموذج المناسب للتفويض الذي يجب أن نستخدمه؟
• ما هو أفضل ممارسة لتطبيق نموذج التفويض؟