Jetty 12.0.x SPNEGO: اضبط اسم الخدمة، لا الـ principal الكامل

ثمة ثلاثة أسماء في إعداد SPNEGO في Jetty: عنوان URI المستخدم لمطابقة المصادقة، والمستخدم الذي يسجّل الدخول عبر JAAS، والخدمة التي تُطلب لها التذكرة. لكل منها غرض مختلف.

في تطبيق Jetty 12.0.x يكون مقتطف كائن المصادقة كما يلي:

var auth = new org.eclipse.jetty.client.SPNEGOAuthentication(
    java.net.URI.create("http://proxy.example:8080"));
auth.setServiceName("HTTP");

يوضح هذا المقتطف مكوّن الخدمة، وليس وصفة كاملة لمصادقة الوكيل. يبقى تسجيل الدخول عبر JAAS وتوجيه الوكيل وتبادل المصادقة الخاص بالطلب منفصلة.

في هذا التطبيق يبني Jetty اسم GSS المستند إلى المضيف بدمج getServiceName() وحرف @ والمضيف المستخدم في تبادل المصادقة. وإن قدّمت [email protected] كمكوّن للخدمة فسيُضاف مضيف آخر. اقرأ عقد هذه الدالة بدل افتراض أنها تقبل principal كاملًا لـ Kerberos.

يتخذ اسم GSS الناتج الشكل المفاهيمي HTTP@hostname. ويُمثَّل principal الخدمة المقابل في KDC عادةً بالصيغة HTTP/hostname. ويجب أن يطابق اسم الوكيل المختار الخدمةَ المسجّلة فعليًا لهذا الحساب؛ فقد يختار عنوان IP أو اسم مستعار هدف تذكرة آخر.

افحص مسار 407 أيضًا

في Jetty 12.0.x يحصل authenticate() على اسم مضيف GSS من request.getHost() ويبني نتيجة باستخدام ترويسة Authorization الافتراضية. ومطابقة كائن مصادقة بعنوان URI للوكيل لا تغيّر بحد ذاتها تلك الخيارات إلى اسم مضيف الوكيل وProxy-Authorization.

لذلك يحتاج تكامل الوكيل إلى مضيف الطلب الصحيح ونتيجة محدّدة بنطاق الوكيل لذلك التبادل. وقد يختلف مضيف طلب HTTPS CONNECT عن مضيف طلب أصل عادي. تحقّق من سلوك التطبيق المثبّت بدل افتراض أن ضابط اسم الخدمة يوفر مسار 407 كاملًا.

بالنسبة إلى 407 افحص تبادل مصادقة الوكيل والمضيف الذي استخدمه ذلك الطلب. أما 401 فيخص مصادقة الأصل. وتذكرة مستخدم صالحة وحدها لا تثبت أن Jetty طلب تذكرة الخدمة الصحيحة أو أن الوسيط قبِلها.