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] लाई सेवा घटकको रूपमा दिँदा अर्को होस्ट थपिन्छ। यो setter ले पूरा Kerberos principal स्वीकार्छ भन्ने मान्नुको सट्टा यसको करार पढ्नुहोस्।

नतिजा 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 ले सही सेवा टिकट माग्यो वा मध्यस्थकर्ताले त्यो स्वीकार्यो भनी प्रमाणित गर्दैन।