في الجامعة، قد يحتاج الشخص الواحد إلى الوصول إلى الموقع الرئيسي، وبوابة أعضاء هيئة التدريس، ونظام المكتبة، ومنصة التعلم، وعشرات التطبيقات الأخرى — ولا أحد يريد تسجيل الدخول بشكل منفصل إلى كل واحد منها. يحل تسجيل الدخول الموحد (SSO) هذه المشكلة من خلال السماح للمستخدم بالمصادقة مرة واحدة فقط، باستخدام مجموعة واحدة من بيانات الاعتماد المؤسسية، والوصول إلى جميع الأنظمة المتصلة. بالنسبة لموقع دروبال الذي يقع في قلب الحضور الرقمي للجامعة، فإن التكامل مع نظام تسجيل الدخول الموحد الخاص بالمؤسسة يُعد أحد أهم عناصر البناء.
يشرح هذا الدليل كيفية عمل تكامل دروبال مع SSO، والأهم من ذلك، كيفية اختيار النهج المناسب. سنغطي التقنيات الأربع التي تعتمد عليها الجامعات — SAML وShibboleth وLDAP وCAS — ومتى يناسب كل منها، وكيفية عمل التكامل على جانب دروبال، وقرارات حوكمة الهوية والأمان التي تتجاهلها معظم الأدلة التفصيلية.
ما الذي يعنيه تسجيل الدخول الموحد فعليًا
تسجيل الدخول الموحد هو نموذج مصادقة يقوم فيه المستخدم بتسجيل الدخول مرة واحدة إلى جهة مركزية موثوقة، ثم يتم التعرف عليه تلقائيًا من قبل كل تطبيق متصل بها. المبدأ الأساسي — والفائدة الأمنية — هو أن التطبيقات الفردية لا تتعامل أبدًا مع كلمة مرور المستخدم. مع وجود SSO، يتم التحقق من بيانات الاعتماد في مكان واحد، وفق مجموعة واحدة من السياسات، بدلاً من تخزينها والتحقق منها بشكل منفصل من قبل كل نظام.
بالنسبة للجامعة، يهم هذا الأمر على عدة مستويات في آن واحد. يحصل الطلاب والموظفون على هوية واحدة عبر عشرات الخدمات. يدير فريق تقنية المعلومات المصادقة مركزيًا، مطبقًا قواعد كلمات مرور متسقة والمصادقة متعددة العوامل في كل مكان. وعندما يغادر شخص ما المؤسسة، فإن تعطيل حساب مركزي واحد يقطع الوصول إلى كل شيء، بدلاً من ترك حسابات دخول متناثرة ومهملة عبر الأنظمة. هذا المزيج من الراحة والتحكم هو السبب في أن SSO يُعد فعليًا متطلبًا أساسيًا لأي منصة ويب مؤسسية جادة.
اللبنة الأساسية: مزود الهوية ومزود الخدمة
ينطوي كل إعداد لـ SSO على دورين، وفهمهما يجعل كل شيء آخر أكثر وضوحًا.
مزود الهوية (IdP) هو الجهة المركزية الموثوقة التي تحتفظ بهويات المستخدمين وتتحقق من بيانات الاعتماد — سواء كانت خدمة Shibboleth الخاصة بالمؤسسة، أو Active Directory، أو خادم CAS. أما مزود الخدمة (SP) فهو التطبيق الذي يريد المستخدم الوصول إليه — في هذه الحالة، موقع دروبال. عندما يحاول المستخدم الوصول إلى مزود الخدمة دروبال، يقوم الأخير بتسليم عملية المصادقة إلى مزود الهوية؛ ويتحقق مزود الهوية من المستخدم ويرسل تأكيدًا، مع سمات مثل الاسم والبريد الإلكتروني والدور؛ ثم يمنح دروبال الوصول بناءً على تلك الاستجابة الموثوقة. في الإعداد الجامعي القياسي، يعمل دروبال كمزود خدمة، بينما يكون النظام الحالي للمؤسسة هو مزود الهوية. إن ضبط هذه العلاقة بشكل صحيح هو أساس كل تكامل لـ SSO.
الأساليب الأربعة: SAML وShibboleth وLDAP وCAS
تعتمد الجامعات عادةً على واحدة من أربع تقنيات لتسجيل الدخول الموحد. وهي تتداخل في الغرض، لكنها تختلف في الأصل والآلية والمكان الذي تناسبه أكثر.
SAML
SAML (لغة ترميز تأكيد الأمان) هو المعيار المفتوح الذي يقوم عليه معظم أنظمة SSO المؤسسية الحديثة. إنه بروتوكول قائم على XML لتبادل بيانات المصادقة والتفويض بين مزود الهوية ومزود الخدمة، ويتكامل مع كل منصة هوية رئيسية تقريبًا — Microsoft Entra ID، وOkta، وADFS، وGoogle Workspace، وغيرها. في دروبال ، يتم التعامل مع SAML من خلال وحدات مساهمة (contributed modules) تتيح للموقع العمل كمزود خدمة، مفوضًا عملية المصادقة إلى أي مزود هوية متوافق مع SAML. إنه الخيار الأوسع توافقًا والأرضية المشتركة التي يمكن لمعظم الأنظمة الأخرى التحدث بها.
Shibboleth
Shibboleth هو تطبيق محدد وواسع الانتشار لبروتوكول SAML، متجذر بعمق في العالم الأكاديمي. إنه العمود الفقري للوصول الموحد في التعليم العالي والبحث العلمي — التقنية الكامنة وراء الاتحادات الأكاديمية الوطنية والدولية التي تتيح لطالب تسجيل الدخول في مؤسسته والوصول إلى موارد في مؤسسة أخرى. من الناحية التقنية، فإن دمج دروبال مع Shibboleth هو تكامل SAML: يعمل دروبال كمزود خدمة SAML، بينما يعمل Shibboleth كمزود هوية. إذا كانت مؤسستك جزءًا من اتحاد هوية أكاديمي، فمن المرجح جدًا أن يكون Shibboleth هو النظام الذي ستتصل به.
LDAP
LDAP (بروتوكول الوصول الخفيف إلى الدليل) ليس بروتوكول SSO بالمعنى نفسه الذي يتمتع به SAML — بل هو بروتوكول للاستعلام عن دليل المستخدمين، وأكثره شيوعًا Microsoft Active Directory. دوره في الجامعة هو أن يكون المصدر الأساسي للهوية: فهو يخزن من هم المستخدمون الموجودون، وعضوياتهم في المجموعات، وسماتهم. يتيح تكامل دروبال مع LDAP للمستخدمين تسجيل الدخول باستخدام بيانات اعتماد الدليل، ويمكنه إنشاء حسابات دروبال تلقائيًا وتعيين الأدوار بناءً على مجموعات الدليل. غالبًا ما يكون LDAP هو الطبقة التي تقع خلف بروتوكول SSO بدلاً من أن يكون بديلاً عنه، وهو شائع بشكل خاص حيث تعمل المؤسسة على منصة Microsoft.
CAS
CAS (خدمة المصادقة المركزية) هو بروتوكول SSO مفتوح المصدر نشأ في جامعة ييل، وما زال يُستخدم على نطاق واسع في التعليم العالي. صُمم خصيصًا لحل مشكلة تسجيل الدخول الموحد لتطبيقات الويب، ويعمل بشكل مريح جنبًا إلى جنب مع مخازن التفويض مثل LDAP. في دروبال ، يقوم تكامل CAS بإعادة توجيه المستخدمين إلى خادم CAS المركزي الخاص بالمؤسسة للمصادقة، ثم يعيدهم إلى الموقع كمستخدمين مسجلي الدخول، مع إمكانية تعيين الأدوار بناءً على استجابة CAS. بالنسبة للجامعات التي تشغل بالفعل نظام CAS على مستوى الحرم الجامعي، فإن ربط دروبال به يُعد خيارًا طبيعيًا.
أي بروتوكول يجب أن تختاره الجامعة؟
في الممارسة العملية، عادةً ما يُملى الاختيار بما تشغّله المؤسسة بالفعل — إذ يتصل دروبال بمزود الهوية الحالي، وليس العكس. يلخص الجدول أدناه متى يناسب كل نهج.
| النهج | ما هو | الأنسب لـ |
|---|---|---|
| SAML | معيار مفتوح للمصادقة الموحدة؛ الأوسع توافقًا. | الاتصال بـ Entra ID أو Okta أو ADFS أو أي مزود هوية يدعم SAML. |
| Shibboleth | تطبيق أكاديمي لـ SAML؛ المعيار المعتمد لاتحادات البحث العلمي. | المؤسسات المنضوية في اتحاد أكاديمي وطني أو دولي. |
| LDAP | بروتوكول دليل؛ المصدر الأساسي لهوية المستخدم. | بيئات Microsoft Active Directory؛ تزويد الأدوار. |
| CAS | بروتوكول SSO مفتوح المصدر يركز على الويب، شائع في الحرم الجامعي. | المؤسسات التي تمتلك خادم CAS على مستوى الحرم الجامعي بالفعل. |
القاعدة العملية بسيطة: حدد مزود الهوية الذي تشغّله مؤسستك بالفعل، ثم اختر تكامل دروبالl الذي يتحدث معه. الجامعة المنضوية في اتحاد أكاديمي تربط دروبال بـ Shibboleth؛ والمؤسسة المعتمدة على Microsoft تربطه عبر SAML بـ Entra ID أو عبر LDAP بـ Active Directory؛ والمؤسسة التي تشغّل خادم CAS في الحرم الجامعي تربطه بـ CAS. نادرًا ما يكون هذا خيارًا يُبنى من الصفر — فالإجابة الصحيحة عادةً ما تحددها البنية التحتية للهوية القائمة بالفعل.
كيف يعمل تسجيل الدخول الموحد على جانب دروبال
على جانب دروبال، يُدار SSO من خلال وحدات مساهمة وليس من خلال النواة، وهناك نظام بيئي ناضج لكل بروتوكول. أيًا كانت الوحدة المستخدمة، فإن التكامل يتولى بعض المهام الأساسية: إعادة توجيه المستخدمين غير المصادق عليهم إلى مزود الهوية، واستقبال استجابة المصادقة والتحقق منها، وربط السمات التي يعيدها مزود الهوية بحساب دروبال.
من المفاهيم الجديرة بالفهم هنا التزويد في الوقت المناسب (just-in-time، أو JIT). فبدلاً من إنشاء حساب دروبال مسبقًا لكل مستخدم محتمل، يقوم تزويد JIT بإنشاء الحساب تلقائيًا في المرة الأولى التي يصادق فيها الشخص بنجاح عبر مزود الهوية، ويملأه بالسمات التي يوفرها مزود الهوية — الاسم والبريد الإلكتروني والدور. هذا ما يجعل SSO قابلاً للتوسع ليشمل جامعة بأكملها: لا يحتاج أي مسؤول لإنشاء آلاف الحسابات يدويًا، ويمكن أن يُدار تعيين الأدوار تلقائيًا بناءً على عضويات المجموعات التي يبلغ عنها مزود الهوية. بالنسبة للمؤسسات التي تُقيّم الوحدات المحددة، توثق صفحات مشروع Drupal.org الرسمية لـ SimpleSAMLphp Authentication، وLDAP، وCAS الخيارات الحالية والمدعومة.
حوكمة الهوية: الجزء الذي تتجاهله معظم الأدلة
تتوقف معظم دروس SSO التعليمية بمجرد أن يعمل تسجيل الدخول. لكن بالنسبة لجامعة تتعامل مع بيانات حساسة للطلاب والموظفين، فإن الأسئلة الأصعب والأهم تتعلق بالحوكمة: من لديه صلاحية الوصول، وكيف تتم إزالة الوصول، وأين تقيم الهوية فعليًا. هنا يتميز التكامل المصمم بعناية عن ذلك الذي يعمل بشكل وظيفي فقط.
المبدأ الأساسي هو أن دروبال يجب ألا يحتفظ بمجموعة منفصلة خاصة به من حسابات المستخدمين إلى جانب مزود الهوية المؤسسي. عندما توجد حسابات دروبال محلية بشكل مستقل، فإنها تنحرف عن التزامن مع الوقت: لا يتم تعطيلها عندما يغادر شخص ما، وتتراكم عليها كلمات مرور ضعيفة بمرور الوقت. الممارسة الموصى بها هي تعطيل المصادقة المحلية بكلمة المرور للجميع باستثناء حساب مسؤول طوارئ واحد ("break-glass")، وتوجيه جميع عمليات المصادقة عبر مزود الهوية، ووراثة المصادقة متعددة العوامل وسياسة كلمات المرور ودورة حياة الحساب الخاصة بالمؤسسة من ذلك المصدر الأعلى. بعبارة أخرى، يصبح نظام هوية المؤسسة — وليس دروبال — هو المصدر الوحيد للحقيقة بشأن من يمكنه تسجيل الدخول.
يوفر هذا النهج فائدة أمنية ملموسة: إلغاء التزويد (deprovisioning). فعندما يتخرج طالب أو يغادر أحد الموظفين، فإن تعطيل حساب هويته المركزي يقطع فورًا وصوله إلى دروبال إلى جانب كل شيء آخر، دون ترك أي تسجيل دخول محلي مهمل خلفه. بالنسبة لمؤسسة مسؤولة عن حماية البيانات، فإن ذلك المفتاح الواحد المركزي لإيقاف التشغيل أكثر أمانًا بكثير من محاولة تعقب حسابات منفصلة عبر كل نظام.
سيناريوهات جامعية: تعدد المواقع، ودورة الحياة، والخريجون
يجلب SSO في سياق الجامعة بعض السيناريوهات التي لا يواجهها موقع شركة واحد أبدًا:
- تسجيل الدخول الموحد متعدد المواقع: تشغّل الجامعات الكبيرة العديد من المواقع — موقع رئيسي بالإضافة إلى مواقع منفصلة للكليات والأقسام ومراكز الأبحاث. يتيح SSO للمستخدم تسجيل الدخول مرة واحدة والتنقل بينها جميعًا بسلاسة، بينما تظل المصادقة مركزية. يتناسب هذا بشكل طبيعي مع بنية دروبال متعددة المواقع، حيث تُدار العديد من المواقع من مكان واحد.
- دورة حياة الهوية: تتغير علاقة الشخص بالجامعة بمرور الوقت — متقدم بطلب، طالب، خريج، وأحيانًا موظف — وتتغير احتياجاته من الوصول تبعًا لذلك. إن استخلاص أدوار دروبال من سمات مزود الهوية يعني أن الوصول يمكن أن يتبع دورة الحياة تلك تلقائيًا، بدلاً من تعديله يدويًا عند كل انتقال.
- الفئات المتمايزة: غالبًا ما يحتاج الطلاب وأعضاء هيئة التدريس والموظفون والخريجون إلى مستويات مختلفة من الوصول إلى أنظمة مختلفة. ولأن مزود الهوية يبلغ عن عضوية المجموعات، يمكن لـدروبال أن يربط كل فئة بالدور المناسب تلقائيًا، مما يحافظ على توافق الصلاحيات مع الحالة الفعلية للمستخدم.
هذه السيناريوهات هي بالضبط السبب في أن تكامل الهوية يُعد جزءًا أساسيًا من بناء منصة جامعية وليس فكرة لاحقة. كما ترتبط بمجموعة أوسع من التكاملات الأكاديمية التي يحتاجها موقع دروبال عادةً — ومن بينها منصة تعلم، وهو ما نتناوله في دليلنا حول تكامل مودل مع دروبال.
أخطاء شائعة في SSO وكيفية تجنبها
- تشغيل حسابات محلية إلى جانب مزود الهوية: أكثر إخفاقات الحوكمة شيوعًا. تنحرف حسابات دروبال المستقلة عن التزامن، ولا تُلغى تلقائيًا، وتتراكم عليها كلمات مرور ضعيفة. وجّه المصادقة عبر مزود الهوية واحتفظ فقط بحساب مسؤول طوارئ محلي واحد.
- نسيان حساب الطوارئ: إذا كان كل تسجيل دخول يعتمد على مزود الهوية وأصبح هذا الأخير غير قابل للوصول، فلن يتمكن أحد من الدخول — بمن فيهم المسؤولون. حساب طوارئ محلي واحد ومحمي بشكل جيد يمنع الإقفال التام.
- تعيين الأدوار بلا مبالاة: منح أدوار دروبال مرتفعة الصلاحيات تلقائيًا بناءً على سمات مزود الهوية قد يمنح صلاحيات إدارية عن غير قصد. اربط كل سمة بأقل امتياز تحتاجه، وعامل الأدوار الإدارية بتدقيق إضافي.
- تجاهل إلغاء التزويد: التركيز فقط على جعل تسجيل الدخول يعمل يترك السؤال الأهم — كيف تتم إزالة الوصول — دون إجابة. صمّم للحظة التي يغادر فيها الشخص، وليس فقط للحظة انضمامه.
- اختيار بروتوكول بمعزل عن السياق: اختيار تقنية SSO دون التحقق مما تشغّله المؤسسة بالفعل يؤدي إلى تعقيد غير ضروري. ابدأ من مزود الهوية القائم واتصل به.
- إهمال ربط السمات: إذا لم تُربط سمات مزود الهوية بشكل صحيح بحقول وأدوار دروبال، فقد يتمكن المستخدمون من تسجيل الدخول لكنهم ينتهون بصلاحيات خاطئة. تحقق من ربط السمات بنفس الدقة التي تتحقق بها من مسار تسجيل الدخول.
عند تنفيذه بشكل صحيح، يجعل تكامل SSO موقع دروبال جزءًا سلسًا وآمنًا من النظام الرقمي البيئي للجامعة — هوية واحدة، محكومة مركزيًا، تمتد عبر كل نظام متصل. إنها قدرة أساسية لأي مؤسسة تُشغّل دروبال على نطاق واسع، وهي جزء من مجموعة أوسع من التكاملات الأكاديمية المستعرضة في نظرتنا العامة على دروبال في التعليم.
أسئلة شائعة حول SSO في دروبال
هل يخزّن دروبال كلمات المرور عند تفعيل SSO؟
لا — وهذه هي الفائدة الأمنية الأساسية لـ SSO. عندما تُفوَّض المصادقة إلى مزود هوية، يتم التحقق من بيانات اعتماد المستخدم من قبل مزود الهوية ولا تُخزَّن أبدًا في دروبال. يعطّل الإعداد الموصى به المصادقة المحلية بكلمة المرور بالكامل، باستثناء حساب مسؤول طوارئ واحد يُحتفظ به للحالات الطارئة. هذا يعني أن كلمات المرور، وسياسة كلمات المرور، والمصادقة متعددة العوامل، كلها تقيم في نظام الهوية المركزي للمؤسسة، ويكتفي دروبال بالثقة في استجابته الموثقة.
هل يمكن لـدروبال استخدام أكثر من مزود هوية واحد في آن واحد؟
نعم، اعتمادًا على الوحدات المستخدمة، يمكن ضبط دروبال للعمل مع مصادر مصادقة متعددة. من الأمثلة الشائعة مؤسسة تصادق الطلاب عبر نظام والموظفين عبر آخر، أو تحتفظ بـ SAML لمعظم المستخدمين بينما تبقي على خيار محلي محدود لمجموعة معينة. يزداد الإعداد تعقيدًا مع كل مصدر إضافي، لذا فالنصيحة العملية هي دعم فقط مزودي الهوية الذين توجد حاجة حقيقية إليهم، والحفاظ على الإعداد بسيطًا بقدر ما تسمح به احتياجات المؤسسة الفعلية.
ما الفرق بين المصادقة والتزويد؟
المصادقة هي التحقق من هوية المستخدم — تأكيد بيانات اعتماده مقابل مزود الهوية. أما التزويد فهو إنشاء حساب المستخدم وسماته والحفاظ عليها في دروبال. يتولى SSO المصادقة؛ ويتولى التزويد في الوقت المناسب (JIT) إنشاء الحساب الذي يليها، حيث يُنشئ حساب دروبال تلقائيًا عند أول تسجيل دخول ويملؤه بسمات مزود الهوية. يعملان معًا: المصادقة تثبت الهوية، والتزويد يمنح تلك الهوية مكانًا ودورًا داخل دروبال.
هل SAML أفضل من CAS للجامعة؟
لا يوجد أفضلية مطلقة لأي منهما — الأمر يعتمد على ما تشغّله مؤسستك بالفعل. SAML، بما في ذلك تطبيقه الأكاديمي Shibboleth، هو الخيار الصحيح للمؤسسات المنضوية في اتحادات بحثية أو الموحدة على منصات هوية مثل Entra ID أو Okta. أما CAS فهو خيار قوي للجامعات التي تشغّل بالفعل خادم CAS على مستوى الحرم الجامعي. يجب أن يتبع القرار البنية التحتية للهوية القائمة بدلاً من ترتيب تجريدي: اربط دروبال بالنظام الذي تثق به مؤسستك بالفعل، ودع ذلك يحدد البروتوكول.