الخلاصة

  • يميز RFC 4422 بين هوية المصادقة المرتبطة ببيانات الاعتماد وهوية التفويض التي يطلب العميل العمل باسمها؛ وعلى الخادم التحقق من الدليل ومن علاقة التمثيل كل على حدة.
  • قد ينشئ نجاح تبادل SASL حالة للجلسة أو يفعّل طبقة أمن، لكنه لا يمنح تلقائيًا حق تنفيذ كل عملية في التطبيق.

علامة خضراء لسؤال محدود

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

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

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

هويتان وراء اسم واحد

يسمي RFC 4422 الهوية المرتبطة ببيانات الاعتماد «هوية المصادقة». أما «هوية التفويض» فهي الهوية التي يطلب العميل أن يعمل باسمها. تتطابق الهويتان غالبًا في الدخول اليومي، ولذلك تختفي المسافة بينهما من الشاشة.

إذا ترك العميل سلسلة هوية التفويض فارغة، فهو يطلب العمل باسم الهوية التي يربطها الخادم ببيانات الاعتماد. لكن الإطار يستوعب الوكالة أيضًا: يثبت A أنه A، ثم يطلب أن يتصرف باسم B.

هنا يلزم قراران. يتحقق الخادم من بيانات A ويستخرج هوية المصادقة، ثم يقرر هل يجوز لـA تمثيل B. يفشل التبادل إذا فشل أي منهما. صحة كلمة مرور لا تجعل معرفة اسم آخر تفويضًا تلقائيًا لانتحال دوره المشروع.

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

ملف التطبيق يكمل المعنى

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

هذه الالتزامات ترسم موضع المعنى. يمكن ترقية آلية اعتماد من دون تعليمها معنى صندوق بريد، ويمكن للتطبيق تبديل الآلية من دون اختراع رسائله من جديد. لكن لا يجوز أن يملأ كل فريق الفراغ بافتراض أن الفريق الآخر طبق السياسة بالفعل.

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

الرقم 235 يجيب عن AUTH فقط

يقدم SMTP AUTH مثالًا محددًا. يجعل RFC 4954 الرمز 235 2.7.0 Authentication Succeeded جواب نجاح لأمر AUTH، ويربط هوية تفويض بجلسة SMTP. هذا وصف لذلك الأمر ولتلك الجلسة، وليس إيصالًا لمعاملة بريد لاحقة.

إذا تفاوض AUTH على طبقة أمن، تعود حالة SMTP إلى بدايتها. يتخلى العميل والخادم عن معلومات القدرات السابقة، وينبغي للعميل إرسال EHLO مرة أخرى. هكذا يمكن لنجاح المصادقة أن يبدأ مرحلة تطبيق جديدة بدل أن يختم الحوار كله.

سياسة الترحيل وفحص المستلمين وضبط المحتوى والطابور والتسليم قرارات تالية. لا يستخدم المثال هنا لإعادة سرد الفرق بين قبول الرسالة وتسليمها؛ بل ليبين أن حتى رمز النجاح الصريح له فعل محدد يجيب عنه.

نجاح لا يثبت هوية أحد

يعرّف RFC 4505 آلية ANONYMOUS لتتيح وصولًا، غالبًا بصلاحيات مقيدة، من دون إلزام المستخدم بإثبات هويته أو كشفها. ومعلومة التتبع الاختيارية غير موثقة ويمكن تزويرها.

لذلك لا تكفي عبارة «نجاح SASL» في السجل لتصنيف مستخدم على أنه موثّق. يجب أولًا قراءة دلالة الآلية. عندما يحول نظام التحليل جلسة مجهولة إلى «شخص جرى التحقق منه»، فإنه يختلق دليلًا حرص المعيار على ألا يقدمه.

قوة البرهان لا تكتب سياسة الوصول

سجل RFC 7677 آليتي SCRAM-SHA-256 وSCRAM-SHA-256-PLUS. استخدام SHA-256 ومعالجة ربط القناة يقويان الجزء القابل للاستبدال من تبادل المصادقة. لكن الآلية لا تتعلم بذلك من يملك موردًا معينًا أو من يحق له تنفيذ أمر حساس.

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

لا تختزل الأدلة في خانة «المستخدم»

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

من دون هذه الفواصل تبدو سرقة بيانات الاعتماد والتفويض الواسع وربط الدليل القديم ومنح التطبيق الزائد متشابهة. بت النجاح يكفي لدفع آلة حالات البروتوكول، ولا يكفي لإعادة بناء المسؤولية.

ينبغي للواجهة أيضًا أن تقول «تم الدخول باسم» عند وصف الجلسة، وألا تقول «يمكنك تعديل هذا المورد» إلا بعد قرار يتعلق به. عندئذ يصبح الرفض بعد الدخول ممارسة لسيطرة الخدمة، لا عطلًا غامضًا.

المصادر