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() request.getHost() कडून GSS होस्टनाव घेते आणि डीफॉल्ट Authorization हेडरसह निकाल तयार करते. proxy URI ने प्रमाणीकरण ऑब्जेक्ट जुळवणे हे त्या निवडी स्वतःच proxy च्या होस्टनावात आणि Proxy-Authorization मध्ये बदलत नाही.

त्यामुळे proxy एकत्रीकरणाला त्या देवाणघेवाणीसाठी योग्य विनंती होस्ट आणि proxy-मर्यादित निकाल आवश्यक आहे. HTTPS CONNECT विनंती आणि सामान्य मूळ विनंतीची होस्ट मूल्ये वेगळी असू शकतात. सेवा-नाव setter संपूर्ण 407 प्रवाह देते असे गृहीत धरण्याऐवजी स्थापित अंमलबजावणीचे वर्तन तपासा.

407 साठी, त्या विनंतीने वापरलेली proxy प्रमाणीकरण देवाणघेवाण आणि होस्ट तपासा. 401 मूळ प्रमाणीकरणाचे आहे. केवळ वैध वापरकर्ता तिकीट हे सिद्ध करत नाही की Jetty ने योग्य सेवा तिकीट मागितले किंवा मध्यस्थाने ते स्वीकारले.