الخلاصة

  • تقول خطة الربع الثالث من عام 2026 إن تطبيق RIPE Database سينتقل من ملف ارتباط آمن على مستوى الموقع إلى ما تسميه «جلسة OIDC 2.0»، وما زال البند معلّماً بأنه قيد التنفيذ.
  • موافقة مزوّد الهوية لا تمنح بحد ذاتها حق تعديل كائن في قاعدة البيانات؛ إذ يبقى التفويض مرتبطاً بحساب SSO وبيانات الاعتماد وعلاقة الهوية بكائن mntner المناسب.
  • أفضل دليل على اكتمال الانتقال هو إيصال إصدار محدود الإفصاح يربط المعيار الدقيق والجلسة المحلية وتسجيل الخروج ووقف الملف القديم واستمرارية مفاتيح API باختبارات سماح ورفض قابلة للتدقيق.

ثلاث لحظات وليست لحظة واحدة

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

تعرض خطة RIPE Database الفصلية تغييراً في هذا المسار. فالخطة الخاصة بالربع الثالث من 2026، والمحدّثة في 11 يونيو، تتضمن بنداً عنوانه “Switch DB web application to OIDC 2.0”. ويقول الوصف إن المصادقة التفاعلية ستتحول من ملف ارتباط آمن مستخدم على مستوى الموقع إلى «جلسة OIDC 2.0». الحالة المنشورة للبند هي “In progress”. هذه صياغة لخطة عمل، لا إعلان عن تشغيل مكتمل ولا وصف تنفيذي كافٍ لاختبار حدوده.

الاسم نفسه يحتاج قدراً من الانضباط. OpenID Connect Core 1.0 يعرّف طبقة هوية مبنية فوق OAuth 2.0. وتضم مجموعة المعايير المنشورة التي راجعناها أيضاً Session Management 1.0 وRP-Initiated Logout 1.0. لا تقدم هذه الوثائق مواصفة نهائية اسمها “OIDC 2.0”. قد تكون العبارة الواردة في الخطة اختصاراً أو اسماً داخلياً لملف تنفيذ أو خطأ تحريرياً أو إشارة إلى تركيب معين. لا تتيح الأدلة العامة الجزم بأي واحد من هذه التفسيرات.

ليس المطلوب تصحيح بطاقة المهمة من الخارج، بل منع البطاقة من أن تصبح بديلاً عن قرار تقني. ينبغي أن يذكر سجل الانتقال مواصفة OpenID Connect وإصدارها وملف OAuth المستخدم، وأن يحدد المصدّر والطرف المعتمد أو العميل بمستوى آمن، وأن يوضح مسار التفويض واستخدام PKCE إن كان منطبقاً. هذه معلومات تصميمية يمكن نشرها من دون نشر رمز وصول أو ملف ارتباط أو عنوان حساب أو بنية داخلية.

مزوّد الهوية لا يمحو الجلسة المحلية

يفصل معيار Session Management بين حالة دخول يحتفظ بها مزوّد OpenID والحالة التي يحتفظ بها الطرف المعتمد. ويتيح معيار RP-Initiated Logout للتطبيق أن يطلب إنهاء جلسة لدى المزوّد. لكن التطبيق يظل مسؤولاً عن تعريف حالته الخاصة: متى ينشئ جلسة محلية، وكم تبلغ مهلة الخمول والعمر المطلق، وماذا تفعل عملية التحديث، وما الذي ينتهي عند تسجيل الخروج من التطبيق وحده أو من مزوّد الهوية.

ومن هنا تظهر مسألة القطع. حين يبدأ النظام بقبول الجلسة الجديدة، هل يتوقف فوراً عن قبول ملف الارتباط القديم؟ هل تُنهى الجلسات المفتوحة قبل الانتقال، أم تُترك حتى انتهاء محدد، أم تُحوّل؟ إذا خرج المستخدم من RIPE Database في علامة تبويب، فهل تنتهي الحالة المحلية فقط أم تُرسل أيضاً إشارة إلى المزوّد؟ وهل يؤدي تعطيل الحساب إلى النتيجة نفسها التي يؤدي إليها انتهاء جلسة متصفح أو إلغاء مفتاح آلي؟

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

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

قرار mntner يأتي بعد المصادقة

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

بذلك لا تصبح جلسة OIDC الصالحة تصريحاً عاماً للتعديل. بعد إثبات الهوية يجب على التطبيق أن يصل إلى حساب SSO ذي الصلة، وأن يحل علاقته بالمشرف أو المشرفين الذين يحمون الكائن، وأن يقيّم العملية المطلوبة. نجاح هذه السلسلة لكائن واحد لا يثبت نجاحها لكل الكائنات، كما أن صلاحية الجلسة لا تعني أن الهوية مرتبطة بالمشرف الصحيح.

هناك دليل برمجي عام على أهمية هذا الفصل. فقد دُمج طلب السحب RIPE-NCC/whois رقم 1688، وعنوانه “Support oauth2”، في 3 مارس 2025. ويُظهر سجل الملفات العام لطلب السحب اختبارات سلبية يُرفض فيها رمز حامل مرتبط بمشرف خاطئ أو بهوية SSO غير المناسبة، ولا يتغير كائن قاعدة البيانات. كما يسجل ملف التغييرات العام عبارة “Support OAuth 2.0 (#1688)” ضمن الإصدار 1.117.

تثبت هذه الاختبارات مبدأً محدوداً ومهماً: التحقق من رمز صالح وتفويض تعديل كائن فحصان مختلفان. لكنها لا تثبت تنفيذ مشروع جلسة المتصفح لعام 2026. فالأثر البرمجي يعود إلى 2025 ويتعلق بدعم رمز حامل، بينما ما زال بند الخطة اللاحق قيد التنفيذ ويصف سطحاً تفاعلياً. الخلط بينهما يجعل التسلسل الزمني يبدو أكثر اكتمالاً مما تسمح به الأدلة.

مفاتيح API لها دورة حياة منفصلة

تشرح وثائق مفاتيح API أن المفتاح يرتبط بحساب RIPE NCC Access. ولكي يسمح بتغييرات قاعدة البيانات، يجب أن يكون الحساب مرتبطاً بكائن mntner عبر السمة auth: SSO. ويمكن حصر المفتاح بمشرف واحد. كما توثق الصفحة انتهاء الصلاحية وإظهار آخر استعمال والإلغاء الفوري.

وتضيف RIPE-843 قواعد لإدارة الحسابات والمفاتيح: المصادقة الثنائية مطلوبة، واسم المستخدم مخصص لشخص واحد، والعمر الأقصى لمفتاح API سنة واحدة، وتعطيل حساب SSO أو إزالة المستخدم من صفة مشرف حساب يعطّل المفتاح المرتبط.

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

الإيصال الذي يمكن مراجعته لاحقاً

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

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

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

المصادر