HTTP युक्ति: प्रॉक्सी-प्राधिकरण और प्राधिकरण हेडर

Question

तो मैं इस परिदृश्य पर लागू करने के लिए कोशिश कर रहा हूँ:

• एक आवेदन मूल प्रमाणीकरण द्वारा सुरक्षित है। आइए मान लें कि यह app.com
• पर होस्ट किया गया है, एप्लिकेशन के सामने एक HTTP प्रॉक्सी प्रमाणीकरण की आवश्यकता है। यह proxy.com

पर होस्ट की है उपयोगकर्ता इसलिए दोनों प्रॉक्सी और एक ही अनुरोध में आवेदन के लिए क्रेडेंशियल्स प्रदान करनी चाहिए, इस प्रकार वह अलग उपयोगकर्ता नाम/पासवर्ड युग्म हैं: एक जोड़ी खुद को आवेदन के खिलाफ प्रमाणित करने के लिए, और एक अन्य उपयोगकर्ता नाम/पासवर्ड जोड़ी प्रॉक्सी के खिलाफ खुद को प्रमाणीकृत करने के लिए।

चश्मा पढ़ने के बाद, मुझे सच में यकीन नहीं है कि मुझे इसे कैसे कार्यान्वित करना चाहिए। मैं क्या करने के लिए सोच रहा था:

1. उपयोगकर्ता बिना किसी प्रमाणीकरण के प्रॉक्सी को HTTP अनुरोध करता है।
2. प्रॉक्सी 407 Proxy Authentication Required का उत्तर देता है और "Proxy-Authenticate: Basic realm="proxy.com" के प्रारूप में Proxy-Authenticate शीर्षलेख देता है।
   प्रश्न: क्या यह Proxy-Authenticate हैडर सही ढंग से सेट है?
3. क्लाइंट फिर Proxy-Authorization शीर्षलेख के साथ अनुरोध को पुनः प्रयास करता है, जो प्रॉक्सी username:password का बेस 64 प्रतिनिधित्व है।
4. इस बार प्रॉक्सी अनुरोध को प्रमाणित करता है, लेकिन फिर अनुप्रयोग 401 Unauthorized शीर्षलेख के साथ उत्तर देता है। उपयोगकर्ता को प्रॉक्सी द्वारा प्रमाणित किया गया था, लेकिन एप्लिकेशन द्वारा नहीं। एप्लिकेशन शीर्षलेख WWW-Authenticate: Basic realm="app.com" जैसे प्रतिक्रिया में जोड़ता है। प्रश्न: यह हेडर मान सही है?
5. ग्राहक Proxy-Authorization शीर्षलेख दोनों के साथ फिर से अनुरोध करता है, और Authorization हेडर के username:password के बेस 64 प्रतिनिधित्व के साथ मूल्यवान हैडर।
6. इस बिंदु पर, प्रॉक्सी सफलतापूर्वक अनुरोध को प्रमाणित करता है, जिसके बाद उपयोगकर्ता को प्रमाणीकृत करने वाले एप्लिकेशन के अनुरोध भी होते हैं। और ग्राहक अंततः एक प्रतिक्रिया वापस हो जाता है।

क्या पूरा वर्कफ़्लो सही है?

Answer 1

हां, यह आपके द्वारा वर्णित स्थिति के लिए एक वैध वर्कफ़्लो जैसा दिखता है, और वे प्रमाणीकृत शीर्षलेख सही प्रारूप में प्रतीत होते हैं।

यह ध्यान रखना दिलचस्प है कि यद्यपि संभवतः, संभवतः यद्यपि एक साथ जुड़े हुए कई प्रॉक्सी को शामिल करने के लिए किसी भी कनेक्शन के लिए संभव है, और प्रत्येक को स्वयं प्रमाणीकरण की आवश्यकता हो सकती है। इस मामले में, प्रत्येक इंटरमीडिएट प्रॉक्सी का क्लाइंट साइड खुद को 407 Proxy Authentication Required संदेश वापस ले जाएगा और स्वयं Proxy-Authorization शीर्षलेख के साथ अनुरोध दोहराएगा; Proxy-Authenticate और Proxy-Authorization हेडर सिंगल-हॉप हेडर हैं जो एक सर्वर से अगले तक पास नहीं होते हैं, लेकिन WWW-Authenticate और Authorization अंत-टू-एंड हेडर हैं जिन्हें क्लाइंट से अंतिम सर्वर तक माना जाता है, द्वारा वर्बैटिम द्वारा पारित किया जाता है मध्यस्थों

चूंकि Basic योजना स्पष्ट रूप से पासवर्ड भेजती है (बेस 64 एक उलटा एन्कोडिंग है) इसका उपयोग आमतौर पर एसएसएल पर किया जाता है।इस परिदृश्य में, एक अलग फैशन में कार्यान्वित किया जाता है क्योंकि यह पासवर्ड अंतिम सर्वर के लिए भेजा देखने से प्रॉक्सी को रोकने के लिए वांछनीय है:

• ग्राहक अनुरोध को आरंभ करने के लिए प्रॉक्सी के लिए एक SSL चैनल को खोलता है, लेकिन बजाय एक नियमित HTTP अनुरोध जमा करने से यह दूरस्थ सर्वर पर एक टीसीपी सुरंग खोलने के लिए a special CONNECT request (अभी भी Proxy-Authorization शीर्षलेख के साथ) सबमिट करेगा।
• क्लाइंट अन्य एसएसएल चैनल को पहले के अंदर घोंसला बनाने के लिए आगे बढ़ता है, जिस पर यह Authorization हेडर सहित अंतिम HTTP संदेश स्थानांतरित करता है।

इस परिदृश्य में प्रॉक्सी केवल मेजबान को जानता है और क्लाइंट को कनेक्ट करता है, न कि आंतरिक एसएसएल चैनल पर प्रसारित या प्राप्त किया गया था। इसके अलावा, नेस्टेड चैनलों का उपयोग क्लाइंट को प्रॉक्सी और सर्वर दोनों के एसएसएल प्रमाणपत्रों को "देखने" की अनुमति देता है, जिससे दोनों को प्रमाणित करने की पहचान मिलती है।