|एकात्मिक प्रॉक्सी प्रमाणीकरण: सेवा खाती आणि बनावटी ओळख
|जेव्हा एकच अनुप्रयोग परस्परसंवादी पद्धतीने चालतो पण वेब सेवा किंवा नियोजित प्रक्रिया म्हणून अयशस्वी होतो, तेव्हा एकात्मिक प्रॉक्सी प्रमाणीकरणामागील सुरक्षा संदर्भ तपासा.
“माझी Windows ओळखपत्रे वापर” याला एक कर्ता लागतो. डेस्कटॉप प्रोग्राममध्ये तो ती चालवणारी व्यक्ती असू शकते. सेवेमध्ये तो सेवेचे खाते असू शकते. वेब अनुप्रयोगात, अभ्यागताचे यशस्वी साइन-इन बाहेर जाणाऱ्या विनंतीचा सुरक्षा संदर्भ आपोआप बदलत नाही.
यामुळेच एकाच मशीनवरील ब्राउझर आणि सर्व्हर-बाजूचा कोड एकात्मिक प्रमाणीकरण असलेल्या प्रॉक्सीकडून वेगवेगळे निकाल का मिळवू शकतात हे स्पष्ट होते. ते वेगवेगळ्या ओळखी सादर करत असावेत.
कोड बदलण्यापूर्वी ओळखींना नावे द्या
- डेस्कटॉप ब्राउझरमध्ये साइन-इन केलेली व्यक्ती.
- अनुप्रयोग प्रक्रिया होस्ट करणारे खाते.
- बाहेर जाणाऱ्या क्रियेसाठी सक्रिय असलेली कोणतीही बनावटी ओळख.
- प्रॉक्सीने प्रत्यक्षात स्वीकारलेले किंवा नाकारलेले खाते.
.NET द्वारे समर्थित एकात्मिक प्रमाणीकरण मार्गांवर, DefaultCredentials सध्याच्या सुरक्षा संदर्भाशी संबंधित आहे. दुसऱ्या मशीनवर पृष्ठ उघडणाऱ्या प्रत्येकासाठी हे जागतिक टोपणनाव नाही.
जर उत्पादन जाणूनबुजून वापरकर्त्यासारखे वागत असेल, तर बनावटी ओळख आणि नेटवर्क प्रतिनिधित्वाच्या कोणत्याही गरजेसाठी स्वतःची समर्थित रचना आवश्यक आहे. सामान्य डीफॉल्ट ओळखपत्र वापरण्याचा स्विच सुरू केल्याने ती रचना प्रस्थापित होत नाही. उलट, सेवा ओळख म्हणून चालण्यासाठी ठरवलेल्या पार्श्वभूमी कामाला कोणीतरी आधी ब्राउझर उघडण्यावर अवलंबून राहू नये.
गुपिते काढून टाकून परस्परसंवादी आणि तैनात सुरुवातीची तुलना करा: खाते संदर्भ, प्रॉक्सी एंडपॉइंट, जाहीर केलेली पद्धत आणि नाकारलेली ओळख. एकवेळची विनंती यशस्वी झाली म्हणून डेस्कटॉप पासवर्ड अनुप्रयोगात कॉपी करणे टाळा. अनुप्रयोगाने वापरायचे असलेले खाते संरचीत करा, नंतर ते मालकी तैनाती नोंदीत दृश्यमान ठेवा.