تسجيل الدخول الموحد SSO وربط النظام مع Active Directory
تسجيل الدخول الموحد SSO يتيح للموظف الدخول إلى نظام سير العمل بالهوية نفسها التي يستخدمها في بقية أنظمة المنشأة، عبر ربطه بـActive Directory. يعتمد على بروتوكولات مثل SAML وOIDC وLDAP لتفويض المصادقة لمزوّد الهوية المركزي، ومزامنة المستخدمين والمجموعات والصلاحيات آليًا. النتيجة: كلمة مرور واحدة، وتوفير حسابات وإلغاؤها فوريًا، وأمن أقوى.
مشكلة الهويات المتعددة
كل نظام جديد بلا SSO يعني هوية إضافية لكل موظف: اسم مستخدم وكلمة مرور جديدين يُنشآن يدويًا، ويُنسيان، ويُعاد ضبطهما، ثم يُنسى تعطيلهما عند مغادرة الموظف. هذه ليست مشكلة راحة فحسب، بل ثغرة أمنية: الحساب المنسي لموظف غادر المنشأة قبل أشهر لا يزال قادرًا على الدخول.
الأخطر أن إدارة الصلاحيات تتشتت. حين تكون لكل نظام قائمة مستخدمين مستقلة، لا أحد يملك صورة كاملة عن «من يصل لماذا». ربط سير العمل بـActive Directory يحلّ الجذر: مصدر هوية واحد يُدار مركزيًا، فالموظف يُنشأ مرة، وصلاحياته تُشتق من مجموعاته، ووصوله يُلغى في مكان واحد فينقطع عن كل الأنظمة المرتبطة — بما فيها سير العمل.
المصادقة (Authentication) تجيب: من أنت؟ والتخويل (Authorization) يجيب: ماذا يحق لك؟ SSO يعالج الأولى بتفويضها لمزوّد الهوية، ومزامنة المجموعات تغذّي الثانية. فهم الفرق يمنع خلطًا شائعًا في مشاريع الربط.
المفاهيم الأساسية
قبل البروتوكولات، لا بد من ثلاثة مصطلحات يتكرر ذكرها في أي مشروع SSO:
- مزوّد الهوية (Identity Provider): الجهة التي تتحقق من الموظف وتصدر «تأكيد هوية». في المنشآت غالبًا Active Directory عبر ADFS أو Azure AD / Microsoft Entra ID.
- مزوّد الخدمة (Service Provider): النظام الذي يثق بذلك التأكيد ويسمح بالدخول — هنا نظام سير العمل.
- تأكيد الهوية (Assertion / Token): الرسالة الموقّعة التي يرسلها مزوّد الهوية لمزوّد الخدمة تقول «هذا فلان، وهذه مجموعاته».
الفكرة أن نظام سير العمل لا يخزّن كلمات المرور ولا يتحقق منها بنفسه، بل يفوّض ذلك لمزوّد الهوية ويثق بتأكيده الموقّع. هذا يقلّل سطح الخطر — كلمة المرور لا تمرّ أصلًا عبر سير العمل — ويجعل سياسات كلمة المرور والمصادقة الثنائية مركزية في مكان واحد.
البروتوكولات: SAML وOIDC وLDAP
ثلاثة بروتوكولات تغطي معظم الحالات، ولكل منها موضعه:
| البروتوكول | يُستخدم لـ | ملاحظة |
|---|---|---|
| SAML 2.0 | الدخول الموحد في بيئات المؤسسات | ناضج وواسع الدعم للويب |
| OpenID Connect | الدخول الموحد الحديث والجوال | مبني على OAuth 2.0 |
| LDAP | الاستعلام المباشر عن المستخدمين والمجموعات | قراءة دليل AD مباشرة |
| SCIM | توفير الحسابات ومزامنتها آليًا | ينشئ ويحدّث ويعطّل |
عمليًا: SAML أو OIDC يتوليان لحظة الدخول (المصادقة)، بينما LDAP أو SCIM يتوليان مزامنة المستخدمين والمجموعات (التوفير والتخويل). الاختيار يعتمد على بيئتك: بيئة تعتمد Active Directory تقليديًا تميل إلى SAML مع LDAP؛ بيئة سحابية على Microsoft Entra ID تميل إلى OIDC مع SCIM. النظام الجيد يدعم أكثر من بروتوكول ليتكيّف مع بنيتك لا العكس. الطبقة نفسها من التكامل البرمجي تُشرح في أهمية API في أنظمة سير العمل.
توفير الحسابات ومزامنة المجموعات
SSO يحل الدخول، لكن القيمة الأكبر في توفير الحسابات آليًا (Provisioning): أن يُنشأ حساب سير العمل ويُحدَّث ويُعطَّل تبعًا لحالة الموظف في Active Directory دون تدخل يدوي:
- الإنشاء: عند إضافة موظف في AD، يُنشأ حسابه في سير العمل تلقائيًا ببياناته.
- اشتقاق الصلاحيات: عضوية الموظف في مجموعات AD (مثل «المالية» أو «مدراء الإدارات») تُترجَم إلى أدوار وصلاحيات في سير العمل.
- التحديث: نقل الموظف أو تغيّر مجموعته ينعكس على صلاحياته في سير العمل.
- التعطيل: تعطيل حساب AD عند الإنهاء يوقف الوصول لسير العمل فورًا.
ربط الأدوار بمجموعات AD بدل تعيينها يدويًا يجعل إدارة الصلاحيات متسقة وقابلة للتدقيق: تريد أن يعتمد كل مدراء المالية فوق حدّ معين؟ اربط الصلاحية بمجموعة «مدراء المالية» في AD، فيدخل ويخرج الأعضاء تلقائيًا مع تغيّر عضويتهم. تفاصيل بناء الأدوار في إدارة الأدوار والصلاحيات RBAC.
قرّر مبكرًا: هل تُشتق كل صلاحيات سير العمل من مجموعات AD، أم أن بعضها يُدار داخل سير العمل نفسه؟ الخلط بلا حوكمة يُنتج تعارضًا. الأنظف: الأدوار العامة من AD، والصلاحيات الدقيقة الخاصة بالمسارات داخل سير العمل بحوكمة واضحة.
مثال تطبيقي: تعيين موظف جديد
تعيّن المنشأة محاسبًا جديدًا في إدارة المالية. تتبّع كيف يعمل الربط من التعيين إلى أول اعتماد:
ما الذي فعله الربط؟ حين أنشأت تقنية المعلومات حساب المحاسب في Active Directory وأضافته لمجموعة «المالية»، ظهر حسابه تلقائيًا في سير العمل عبر المزامنة، واشتُقّت صلاحياته من عضويته: يرى طلبات الصرف ويعالجها ضمن حدّه. دخل بالكلمة نفسها التي يستخدمها للبريد والملفات — دون هوية جديدة. ولو انتقل لاحقًا لإدارة أخرى، تتغيّر مجموعته في AD فتتبعها صلاحياته في سير العمل بلا طلب يدوي.
دورة حياة الوصول وإلغاؤه
أخطر لحظة أمنية في أي منشأة هي مغادرة موظف. بلا ربط مركزي، يبقى حسابه حيًّا في أنظمة متفرقة نسيها الجميع. الربط يجعل دورة الوصول محكمة من طرفيها:
- الدخول (Joiner): الحساب والصلاحيات تُنشأ تلقائيًا عند التعيين، فيبدأ الموظف العمل دون انتظار إعداد يدوي.
- التغيير (Mover): النقل أو الترقية يعيد اشتقاق الصلاحيات آليًا، فلا يحمل الموظف صلاحيات وظيفة قديمة.
- المغادرة (Leaver): تعطيل حساب AD يقطع الوصول لسير العمل فورًا، وتبقى طلباته وسجله محفوظة للتدقيق.
هذا الانضباط (Joiner-Mover-Leaver) من أهم ما يفحصه أي تدقيق أمني: هل الوصول يعكس الحالة الوظيفية الفعلية لحظيًا؟ الربط بـAD يجعل الإجابة نعم بحكم التصميم، لا بحكم المتابعة اليدوية. راجع أثر ذلك على السجل في توثيق عمليات الدخول والتعديل والاعتماد.
الأمن والاعتبارات العملية
الربط بمزوّد الهوية يركّز الأمن في مكان واحد — وهذا قوة وحمل في آن. اعتبارات عملية مهمة:
- المصادقة الثنائية (MFA): تُطبَّق مركزيًا في مزوّد الهوية فتنسحب على سير العمل تلقائيًا، دون إعداد منفصل.
- خطة الاحتياط: ماذا لو تعطّل مزوّد الهوية؟ يجب وجود آلية دخول طوارئ محكومة لمسؤولين محددين، لئلا يتوقف العمل كليًّا.
- تشفير التأكيدات: رسائل SAML/OIDC موقّعة ومشفّرة عبر TLS، فلا تُزوَّر ولا تُلتقط. راجع تشفير البيانات أثناء النقل والتخزين.
- الاستضافة داخل السعودية: عند ربط هويات المنشأة، يهمّ مكان استضافة النظام. راجع استضافة بيانات نظام الموافقات داخل السعودية.
الخلاصة: SSO ليس مجرد راحة، بل تحسين أمني حقيقي حين يُنفَّذ بعناية — كلمة مرور أقل تُنسى، ووصول ينعكس على الحالة الفعلية، وسياسات مركزية تُطبَّق بلا استثناء.
الأسئلة الشائعة
هل يخزّن نظام سير العمل كلمات مرور الموظفين عند تفعيل SSO؟
لا. جوهر SSO أن نظام سير العمل يفوّض المصادقة لمزوّد الهوية (Active Directory) ولا يخزّن كلمات المرور ولا يتحقق منها بنفسه. الموظف يدخل بياناته في مزوّد الهوية فقط، الذي يرسل تأكيدًا موقّعًا لسير العمل. هذا يقلّل سطح الخطر لأن كلمة المرور لا تمرّ أصلًا عبر النظام، ويجعل سياسات كلمة المرور مركزية.
ما الفرق بين SAML وOIDC وLDAP في هذا السياق؟
SAML وOIDC بروتوكولا مصادقة يتوليان لحظة الدخول الموحد؛ SAML ناضج وشائع في بيئات المؤسسات، وOIDC أحدث وأنسب للجوال. LDAP بروتوكول استعلام يقرأ المستخدمين والمجموعات من دليل Active Directory مباشرة، ويُستخدم للمزامنة والتوفير. عمليًا تجمع الحلول بين بروتوكول مصادقة وآخر للمزامنة حسب بيئتك.
هل يمكن اشتقاق صلاحيات سير العمل من مجموعات Active Directory؟
نعم، وهو أفضل الممارسات. عضوية الموظف في مجموعات AD تُترجَم إلى أدوار وصلاحيات في سير العمل، فتُدار الصلاحيات مركزيًا وتتغيّر تلقائيًا مع تغيّر العضوية. هذا يجعل الإدارة متسقة وقابلة للتدقيق. القرار الحوكمي المهم هو تحديد أي صلاحيات تُشتق من AD وأيها تُدار داخل سير العمل، حتى لا يقع تعارض.
ماذا يحدث لوصول الموظف عند مغادرته المنشأة؟
يُلغى فورًا. تعطيل حساب الموظف في Active Directory يقطع وصوله لنظام سير العمل مباشرة، لأن المصادقة تمرّ عبر مزوّد الهوية المركزي. تبقى طلبات الموظف وسجله محفوظة لأغراض التدقيق، لكن قدرته على الدخول تنتهي في مكان واحد. هذا يعالج أخطر ثغرة أمنية: الحساب الحي لموظف غادر.
ماذا لو تعطّل مزوّد الهوية؟ هل يتوقف النظام كليًّا؟
هذا اعتبار تصميمي مهم. لأن المصادقة تعتمد على مزوّد الهوية، يجب وجود خطة احتياط: آلية دخول طوارئ محكومة لعدد محدود من المسؤولين تعمل عند تعذّر الوصول لمزوّد الهوية. كما يُفضَّل استضافة مزوّد الهوية بموثوقية عالية. الهدف ألا يتحول تركيز المصادقة في مكان واحد إلى نقطة فشل توقف العمل.
ملخص سريع
ربط سير العمل بـActive Directory عبر SSO يجعل الهوية مركزية: الموظف يدخل بكلمة مرور واحدة، والنظام يفوّض المصادقة لمزوّد الهوية دون تخزين كلمات المرور. البروتوكولات (SAML/OIDC للدخول، LDAP/SCIM للمزامنة) تنشئ الحسابات وتشتق الصلاحيات من مجموعات AD وتلغي الوصول فور المغادرة. النتيجة أمن أقوى وإدارة أبسط ودورة وصول تعكس الحالة الوظيفية لحظيًا.
جرّب النظام على إجراء من إجراءاتك
اطلب عرضًا توضيحيًا مخصصًا: اختر إجراءً حقيقيًا من منشأتك ونُريك كيف يعمل داخل النظام من التقديم حتى الاعتماد.