SSO الذي بدأه IdP مقابل SSO الذي بدأه SP#

المصطلحات#

• موفر الهوية (IdP): الخدمة التي تخزن وتتحقق من هويات المستخدمين.
• مزود الخدمة (SP): موقع ويب أو خدمة تقدم خدمات للمستخدمين.
• تسجيل دخول واحد (SSO): خدمة جلسة ومصادقة المستخدم تسمح للمستخدم باستخدام مجموعة واحدة من بيانات تسجيل الدخول (مثل الاسم وكلمة المرور) للوصول إلى تطبيقات متعددة.
• SAML: لغة ترميز تأكيد الأمان هي معيار مفتوح لتبادل بيانات المصادقة والتفويض بين الأطراف، لا سيما بين مزود الهوية ومزود الخدمة. إنها بروتوكول مستخدم بشكل شائع لتسجيل الدخول الأحادي. بمجرد أن يتم مصادقة المستخدم بنجاح بواسطة IdP، يرسل IdP تأكيد SAML إلى SP، والذي يتحقق منه SP ويمنح المستخدم الوصول.
• OIDC: OpenID Connect هو بروتوكول أكثر حداثة وأمانًا لتسجيل الدخول الأحادي. يتم بناؤه على OAuth 2.0 ويوفر طريقة للتحقق من هوية المستخدم بناءً على المصادقة التي يجريها IdP. بمجرد أن يتم مصادقة المستخدم بنجاح بواسطة IdP، يرسل IdP رمزًا بتنسيق JWT إلى SP، والذي يتحقق منه SP ويمنح المستخدم الوصول.

SSO الذي بدأه SP#

كما يوحي الاسم، يتم بدء SSO الذي بدأه SP بواسطة مزود الخدمة. يبدأ المستخدم عملية المصادقة عن طريق الوصول إلى مورد على موقع الويب الخاص بـ SP. ثم يقوم SP بإعادة توجيه المستخدم إلى IdP للمصادقة. بمجرد مصادقة المستخدم، يقوم IdP بإنشاء رمز (OIDC) أو تأكيد SAML (SAML) وإرساله مرة أخرى إلى SP. يتحقق SP من صحة الرمز أو التأكيد ويمنح المستخدم الوصول.

1. يزور المستخدم موقع الويب الخاص بـ SP ويحاول الوصول إلى مورد.
2. ينقر المستخدم على زر تسجيل الدخول لموفر SSO (مثل Google، Azure AD، Okta، إلخ).
3. يقوم SP بإعادة توجيه المستخدم إلى IdP للمصادقة.
4. يسجل المستخدم الدخول إلى IdP.
5. يرسل IdP رمزًا أو تأكيدًا مرة أخرى إلى SP.
6. يتحقق SP من صحة الرمز أو التأكيد ويمنح المستخدم الوصول.

SSO الذي بدأه IdP#

على عكس SSO الذي بدأه SP، يبدأ SSO الذي بدأه IdP بواسطة موفر الهوية. يبدأ المستخدم عملية المصادقة من موقع IdP. عادة، سيجد المستخدم قائمة بالتطبيقات SP المدعومة على بوابة IdP. ينقر المستخدم على تطبيق SP ويتم إعادة توجيهه إلى موقع SP مع هوية تم المصادقة عليها مسبقًا.

1. يسجل المستخدم الدخول إلى IdP.
2. يزور المستخدم بوابة IdP ويختار تطبيق SP.
3. يتحقق IdP من الجلسة الحالية للمستخدم ويعيد توجيه المستخدم إلى SP بهوية SSO تم المصادقة عليها مسبقًا.
4. يتحقق SP من صحة هوية SSO ويمنح المستخدم الوصول.

SSO الذي بدأه IdP مقابل SSO الذي بدأه SP#

مزايا SSO الذي بدأه IdP مقارنة بـ SSO الذي بدأه SP#

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

مخاطر SSO الذي بدأه IdP مقارنة بـ SSO الذي بدأه SP#

يحمل SSO الذي بدأه IdP مخاطر أكبر مقارنة بـ SSO الذي بدأه SP.

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

2. تثبيت الجلسة: نظرًا لأن SP لا يبدأ عملية المصادقة، يمكن تثبيت جلسة المستخدم على جلسة IdP. قد يؤدي ذلك إلى هجمات تثبيت الجلسة حيث يمكن للمهاجم تثبيت جلسة المستخدم على جلسة IdP والحصول على وصول غير مصرح به إلى حساب المستخدم.

3. هجمات التصيد: يمكن أن يكون SSO الذي بدأه IdP عرضة لهجمات التصيد. يمكن لممثل ضار خداع المستخدم لزيارة بوابة IdP مزيفة وسرقة بيانات اعتماد المستخدم. بمجرد أن يسجل المستخدم الدخول، يمكن للمهاجم إعادة توجيه المستخدم إلى SP بهوية مصادقة مسبقًا.

4. عدم التأكد من صحة الطلب: في SSO الذي بدأه SP، عادة ما يتضمن SP معلومات الأمان الضرورية في الطلب إلى IdP للحفاظ على سلامة الطلب. بمجرد أن يستقبل SP استجابة المصادقة، سيقوم بالتحقق من صحة هذه المعلومات لمنع هجمات CSRF. على سبيل المثال، البارامتر state في OIDC و RelayState في SAML. ومع ذلك، في SSO الذي بدأه IdP، لا يبدأ SP عملية المصادقة، وبالتالي ليس لدى SP أي تأكيد على صحة الطلب.

قيود SSO الذي بدأه IdP مقارنة بـ SSO الذي بدأه SP#

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

لكن في SAML، يكون SSO الذي بدأه IdP ممكنًا. يمكن لـ IdP توليد تأكيد SAML دون أن يبدأ SP عملية المصادقة. في SAML SSO الذي بدأه IdP، يمكن إرسال تأكيد SAML بدون RequestID و RelayState بشكل مباشر إلى عنوان URL ACS الخاص بـ SP. يجب أن يكون SP قادرًا على معالجة هذا النوع من التأكيد ومنح المستخدم الوصول. (ملاحظة: بدون RequestID و RelayState، ليس لدى SP أي تأكيد على سلامة الطلب).

الخلاصة#

على الرغم من أن SSO الذي بدأه IdP يوفر طريقة مركزية لإدارة وصول المستخدم إلى تطبيقات متعددة، إلا أنه يحمل المزيد من المخاطر مقارنة بـ SSO الذي بدأه SP. يعتبر SSO الذي بدأه SP أكثر أمانًا ويوفر المزيد من التأكيد على سلامة طلب المصادقة. يُوصى باستخدام SSO الذي بدأه SP لكل من SSO المعتمد على OIDC و SAML.