Jetty 12.0.x SPNEGO: सेवा का नाम सेट करें, पूरा principal नहीं

Jetty SPNEGO कॉन्फ़िगरेशन में तीन नाम होते हैं: प्रमाणीकरण मिलान के लिए प्रयुक्त 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");

यह अंश सेवा घटक दर्शाता है, proxy प्रमाणीकरण की पूरी विधि नहीं। JAAS लॉगिन, proxy रूटिंग और अनुरोध का प्रमाणीकरण विनिमय अलग ही रहते हैं।

इस कार्यान्वयन में Jetty getServiceName(), @ वर्ण और प्रमाणीकरण विनिमय के होस्ट को मिलाकर GSS होस्ट-आधारित नाम बनाता है। [email protected] को सेवा घटक के रूप में देने पर एक और होस्ट जुड़ जाएगा। यह मानने के बजाय कि यह पूरा Kerberos principal स्वीकार करता है, इस setter का अनुबंध पढ़ें।

परिणामी GSS नाम का वैचारिक रूप HTTP@hostname है। KDC का संगत सेवा principal आमतौर पर HTTP/hostname के रूप में दर्शाया जाता है। चुना गया proxy नाम वास्तव में पंजीकृत सेवा से मेल खाना चाहिए उस खाते के लिए; IP पता या उपनाम किसी दूसरे टिकट लक्ष्य का चयन कर सकता है।

407 पथ की भी जाँच करें

Jetty 12.0.x में authenticate() GSS होस्टनाम request.getHost() से लेता है और डिफ़ॉल्ट Authorization हेडर के साथ परिणाम बनाता है। proxy URI से प्रमाणीकरण ऑब्जेक्ट का मिलान करना अपने आप उन चयनों को proxy के होस्टनाम और Proxy-Authorization में नहीं बदलता।

इसलिए proxy एकीकरण को उस विनिमय के लिए सही अनुरोध होस्ट और proxy-सीमित परिणाम चाहिए। HTTPS CONNECT अनुरोध और सामान्य मूल अनुरोध के होस्ट मान अलग हो सकते हैं। यह मानने के बजाय कि सेवा-नाम setter पूरा 407 प्रवाह देता है, स्थापित कार्यान्वयन का व्यवहार जाँचें।

407 के लिए, उस अनुरोध द्वारा प्रयुक्त proxy प्रमाणीकरण विनिमय और होस्ट जाँचें। 401 मूल प्रमाणीकरण का है। केवल एक वैध उपयोगकर्ता टिकट यह सिद्ध नहीं करता कि Jetty ने सही सेवा टिकट मांगा या मध्यस्थ ने उसे स्वीकार किया।