تسجيل الدخول الموحّد يجعل مزوّد الهوية لديك يؤكد من المستخدم بدل أن يحفظ نظام التذاكر كلمة مرور له، عبر SAML 2.0 أو OIDC. لكن الدخول نصف المسألة فقط؛ النصف الآخر هو التزويد: من ينشئ الحساب، ومن يحذفه حين يغادر الموظف. الإنشاء عند أول دخول (JIT) لا يحذف شيئًا — الحذف يحتاج SCIM.
تُطلب ميزة تسجيل الدخول الموحّد عادةً براحة المستخدم: «لا نريد كلمة مرور أخرى». هذا أضعف أسبابها. السبب الحقيقي أمني: كل نظام يحفظ كلمات مرور مستقلة هو مخزن أسرار إضافي يمكن اختراقه، وكل حساب لا يُلغى عند مغادرة صاحبه هو باب مفتوح. تسجيل الدخول الموحّد يغلق الأول، والتزويد الآلي يغلق الثاني — وأغلب المشاريع تنفّذ الأول وتنسى الثاني.
المفاهيم بدقة
التعريف الثالث مصدر لبس متكرر. «اربطه بـActive Directory» جملة تعني ثلاثة أشياء مختلفة: ربط LDAP مباشر (النظام يسأل الدليل عن المستخدم وكلمة مروره)، أو دخول موحّد عبر AD FS، أو دخول موحّد عبر Entra ID بعد مزامنة الدليل معه. الأول أبسط وأضعف — كلمة المرور تمر عبر التطبيق ولا مصادقة متعددة العوامل. الثالث هو الاتجاه السائد. اسأل: أي واحد تقصد؟
SAML 2.0 مقابل OIDC
| الوجه | SAML 2.0 | OpenID Connect (OIDC) |
|---|---|---|
| الأساس | معيار قائم على XML، ناضج ومستقر منذ سنوات طويلة. | طبقة هوية فوق OAuth 2.0، تستخدم JSON ورموز JWT. |
| شكل الشهادة | Assertion بصيغة XML موقّعة، تُرسل عادةً عبر المتصفح بطلب POST. | ID Token بصيغة JWT، أخف وأسهل في المعالجة والتصحيح. |
| الإعداد | تبادل بيانات وصفية وشهادة X.509 بين الطرفين يدويًا غالبًا. | نقطة اكتشاف تُعرّف الإعدادات تلقائيًا، وتدوير المفاتيح يتم دون تدخل عادةً. |
| الملاءمة | تطبيقات الويب المؤسسية. الأوسع دعمًا في المنتجات القائمة. | تطبيقات الجوال وواجهات الصفحة الواحدة والواجهات البرمجية. |
| نقطة الألم | انتهاء صلاحية شهادة التوقيع يقطع الدخول للجميع فجأة، وغالبًا بلا تنبيه مسبق. | التطبيق الخاطئ لعمليات التحقق من الرمز يفتح ثغرات؛ التفاصيل الأمنية دقيقة. |
| الحكم | اختره إن كان مستخدمًا لديك بالفعل ومدعومًا في كل أنظمتك. | اختره للأنظمة الجديدة وحيث الجوال جزء أساسي من الاستخدام. |
الخلاصة العملية: البروتوكول ليس قرارًا استراتيجيًا. كلاهما آمن إن نُفّذ صحيحًا، والفرق في التفاصيل التشغيلية لا في المتانة. القاعدة: استخدم ما يدعمه مزوّد هويتك ونظامك معًا بأقل تعقيد. إن دعم الطرفان الاثنين، فـOIDC عادةً أقل صيانة على المدى الطويل. لا تُطل الجدل هنا؛ الوقت الحقيقي يجب أن يُصرف على القسم التالي.
التزويد: الجزء الذي ينساه الجميع
هنا لبّ المقال. تسجيل الدخول الموحّد يجيب عن سؤال «هل هذا هو فلان؟» ولا يجيب عن «هل ما زال فلان موظفًا لدينا؟». الفرق بينهما هو ما يقرر إن كان حساب من غادر قبل ستة أشهر ما زال يفتح تذاكر عملائك.
الخطوة الرابعة هي الفجوة الأمنية الأشهر في هذه المشاريع كلها. قد يقول قائل: ما دام الدخول عبر IdP وقد عُطّل الحساب هناك، فلن يستطيع الدخول أصلًا. صحيح جزئيًا وخطر كليًا، لثلاثة أسباب: قد تبقى جلسته الحالية حية حتى تنتهي مهلتها؛ وقد يكون له مسار دخول محلي بديل أُنشئ يومًا للطوارئ ونُسي؛ والأهم أن حسابه يبقى ظاهرًا كمستخدم نشط — يُسنَد إليه تذاكر، ويُحتسب في الترخيص، ويظهر في تقارير التدقيق كوصول قائم. تعطيل الدخول ليس هو إلغاء الوصول.
من المجموعات إلى الأدوار
الشهادة الواردة من IdP تحمل سمات: البريد، والاسم، والإدارة، وعضويات المجموعات. تخطيط هذه السمات إلى أدوار النظام هو ما يجعل الحوكمة آلية بدل أن تكون نية. مثال افتراضي: عضوية مجموعة «فريق الدعم — المستوى الثاني» في الدليل تمنح دور فني أول؛ ومجموعة «مدراء الخدمة» تمنح دور مشرف. حين يُنقل الموظف بين الفريقين، يتغير دوره في النظام من تلقاء نفسه دون تذكرة ولا طلب.
الشرط الذي يُسقط هذا التصميم: نظافة المجموعات في الدليل. إن كانت مجموعاتك متراكمة منذ سنوات بأسماء لا تعبّر عن محتواها وعضويات لا أحد يراجعها، فأنت تبني الأدوار على أساس متحرك، والنتيجة أسوأ من الإسناد اليدوي لأنها خاطئة وتبدو آلية وموثوقة. نظّف المجموعات أولًا، ثم اربط. تفاصيل بناء نموذج الأدوار في صلاحيات المستخدمين في نظام التذاكر.
- ما البروتوكولات المدعومة: SAML 2.0، OIDC، LDAP؟ وهل الدعم في كل الباقات أم في الباقة الأعلى فقط؟
- هل تدعمون SCIM لتزويد الحسابات وإلغائها؟ إن لا، فما البديل المقترح لإلغاء الوصول آليًا؟
- هل يُدعم الدخول المبدوء من مزوّد الخدمة (SP-initiated)، أم من IdP فقط؟
- كيف تُخطَّط المجموعات إلى الأدوار، وهل يُعاد التقييم عند كل دخول أم عند الإنشاء فقط؟
- كيف تُدار شهادة التوقيع وتُدوَّر، ومتى يُنبَّه المسؤول قبل انتهائها؟
- هل يوجد حساب طوارئ محلي (break-glass) خارج مسار IdP؟ وكيف يُحمى ويُراقب استخدامه؟
- ما مدة الجلسة، وهل يمكن إنهاء جلسات مستخدم بعينه فورًا من لوحة الإدارة؟
- هل يدعم النظام تسجيل الخروج الموحّد (SLO)، وما حدوده الواقعية؟
- هل يمكن إجبار كل المستخدمين على المرور بـIdP ومنع الدخول بكلمة مرور محلية؟
- هل تُسجَّل محاولات الدخول الناجحة والفاشلة في سجل تدقيق قابل للتصدير؟
- هل يُدعم أكثر من مزوّد هوية في الوقت نفسه (موظفون داخليون ومقاولون مثلًا)؟
- ماذا يحدث للمستخدمين الخارجيين — العملاء على البوابة — هل يخضعون للمسار نفسه أم لمسار منفصل؟
البند السادس يستحق تفصيلًا: حساب الطوارئ ضرورة لا خيار. إن تعطّل IdP أو أُسيء ضبط الربط، فبلا حساب محلي واحد تكون قد أقفلت على نفسك الباب ولا سبيل للدخول لإصلاح الشيء. اجعله حسابًا واحدًا بكلمة مرور طويلة محفوظة في خزنة أسرار، ومراقبًا: أي استخدام له يجب أن يُطلق تنبيهًا فوريًا. هذا النمط يتقاطع مع ما تطلبه ضوابط الهيئة الوطنية للأمن السيبراني في أنظمة التذاكر من إدارة للهويات ومراقبة للحسابات المميّزة، وهو من أوائل ما يُسأل عنه في أي تقييم أمني للمزوّد. وإن كنت تقيّم منصّات، فاجعل دعم الهوية والتزويد بندًا صريحًا في جدول المقارنة بجانب بقية مزايا نظام التذاكر — لا سؤالًا يُؤجَّل إلى ما بعد التوقيع، حين يتحول من متطلب إلى مشروع تطوير مدفوع.
الأسئلة الشائعة
هل SAML أفضل من OIDC؟
لا يوجد أفضل مطلق. كلاهما آمن إن نُفّذ صحيحًا. SAML أوسع دعمًا في المنتجات المؤسسية القائمة، وOIDC أخف وأسهل صيانة وأنسب للجوال والواجهات البرمجية. المعيار العملي الوحيد: ما الذي يدعمه مزوّد هويتك ونظامك معًا بأقل تعقيد؟ إن دعما الاثنين فاختر OIDC للأنظمة الجديدة، ولا تُطل الجدل.
ما الفرق بين JIT وSCIM؟
JIT يُنشئ الحساب لحظة أول دخول من بيانات الشهادة — تفاعلي، ولا يعرف إلا بمن يحضر. SCIM يدفع من IdP إلى النظام: أنشئ، عدّل، عطّل — استباقي، ويعمل حتى لو لم يدخل المستخدم قط. الفرق الحاسم أن JIT لا يستطيع تعطيل أحد لأنه لا يعمل إلا حين يأتي المستخدم، ومن غادر لا يأتي.
هل يكفي تعطيل الحساب في Active Directory؟
لمنع الدخول الجديد نعم غالبًا، ولإلغاء الوصول لا. تبقى الجلسة الحالية حية حتى تنتهي مهلتها، وقد يوجد مسار دخول محلي منسي، ويبقى الحساب ظاهرًا كمستخدم نشط يُسنَد إليه العمل ويُحتسب في الترخيص. الإلغاء الحقيقي يحتاج SCIM أو مراجعة دورية موثّقة يملكها شخص بالاسم.
هل يعمل تسجيل الدخول الموحّد للعملاء الخارجيين؟
عادةً لا، ولا ينبغي. مزوّد هويتك يعرف موظفيك لا عملاءك. الشائع أن يكون للموظفين مسار IdP، وللعملاء على بوابة الخدمة الذاتية مسار منفصل — حساب محلي، أو رابط دخول لمرة واحدة، أو تحقق برمز. الاستثناء: عميل مؤسسي كبير يطلب ربط دليله بنظامك، وهذا يحتاج دعم عدة مزوّدي هوية في وقت واحد.
لماذا يفشل الدخول برسالة غامضة عن الشهادة؟
الأسباب الثلاثة الأشهر في SAML: انتهاء صلاحية شهادة التوقيع؛ أو فارق زمني بين الخادمين يجعل الشهادة تبدو غير صالحة بعد (اضبط مزامنة الوقت على الطرفين)؛ أو عدم تطابق معرّف الجهة أو رابط الاستقبال بعد تغيير نطاق. ابدأ التشخيص بالتقاط الشهادة الخام وفحص أوقاتها ومُصدِرها قبل أي شيء آخر.