मेरे पास दो एप्लिकेशन हैं। मुझे आवेदन से एक आवेदन के लिए एक एकल साइनऑन करने की जरूरत है b।दूरस्थ लॉगिन करने के लिए जावा वेब सेवा कैसे लिखें?
मैं वेब सेवा का उपयोग करने के बारे में सोच रहा हूं। मुझे आश्चर्य है कि मैं उस दृष्टिकोण के बारे में कैसे जा सकता हूं।
क्या कोई सलाह दे सकता है?
आप मौजूदा ओपन सोर्स उत्पाद, CAS का उपयोग कर सकते हैं और इसे स्वयं विकसित करने के बजाय इसे कार्यान्वित कर सकते हैं। इस तरह आप उसी प्रोटोकॉल का समर्थन करने वाले अन्य अनुप्रयोगों के साथ एकीकृत करने में सक्षम होंगे। यहां तक कि यदि आप अपने कोड का उपयोग करने के बजाय अपना खुद का कार्यान्वयन करने का निर्णय लेते हैं, तो वेब साइट पर बहुत सारे विचार प्रस्तुत किए गए हैं जो आपके लिए विचार करने के लिए उपयोगी होंगे।
यदि अनुप्रयोग एक ही सर्वर में होस्ट किए जाते हैं, तो आप इसे एकल साइन ऑन करने के लिए कॉन्फ़िगर कर सकते हैं। उदाहरण के लिए, टॉमकैट में यह Valve के साथ हासिल किया जाता है।
यदि अनुप्रयोग विभिन्न वातावरण में हैं, तो एक सुरक्षित वेब सेवा एक अच्छा विचार है। उदाहरण के लिए आप सार्वजनिक - निजी कुंजी जोड़ी बना सकते हैं और एप्लिकेशन बी (सर्वर) क्लाइंट प्रमाण पत्र पर एप्लिकेशन (क्लाइंट) प्रमाणीकरण कर सकते हैं। इसका मतलब यह है कि एप्लिकेशन क्लाइंट प्रमाण पत्र के साथ आवेदन बी के सभी अनुरोधों पर हस्ताक्षर करेगा। पूर्ण समाधान के लिए आर्किटेक्चर के बारे में अधिक जानकारी की आवश्यकता है।
क्या आप एक एप्लिकेशन सर्वर का उपयोग कर रहे हैं? आपके अनुप्रयोगों के लिए पर्यावरण क्या है?
वेब सेवा सुरक्षा उपयोगकर्ता नाम टोकन प्रोफ़ाइल नामक वेब सेवाओं का उपयोग करके पहचान प्रसारित करने के लिए एक मानक है। यहां एक त्वरित overview है। आप उपयोगकर्ता नाम/पासवर्ड या विभिन्न टोकन जैसे X.50 9 प्रमाणपत्र या SAML दावा भेज सकते हैं। कुछ एप्लिकेशन सर्वर वेब सेवा स्टैक WSS उपयोगकर्ता नाम टोकन प्रोफाइल, जेबॉस, वेबस्पेयर, और वेबलॉगिक को संभालेगा। अन्यथा वेब सेवा कोड को इसे संभालना है। यह दृष्टिकोण आपके पर्यावरण के आधार पर बहुत बोझिल हो सकता है।
एकल साइन-ऑन के लिए मानक है, जिसे SAML कहा जाता है। फिर, यह आपके उपयोग के मामले के लिए बहुत भारी वजन हो सकता है।
ओरेकल भूमि में मुझे पता है कि एक विश्वसनीय अनुप्रयोग की अवधारणा है। असल में यदि आपके पास दोनों अनुप्रयोगों का नियंत्रण है तो आप इसे इस तरह सेट कर सकते हैं:
एप्लिकेशन ए एप्लिकेशन बी भेजता है, 1) एप्लिकेशन ए का उपयोगकर्ता नाम और पासवर्ड और 2) वर्तमान उपयोगकर्ता का उपयोगकर्ता नाम। चूंकि बी एप्लिकेशन ए को जानता है और भरोसा करता है, इसलिए उसे उपयोगकर्ता के प्रमाण-पत्रों को सत्यापित करने की आवश्यकता नहीं है, क्योंकि यह जानता है कि एप्लिकेशन ए ने इसके लिए पहले से ही ऐसा किया है।
मुझे लगता है कि यदि आपके पास कस्टम एप्लिकेशन बी है तो आप ऐसा कुछ करने में सक्षम हो सकते हैं। यदि आपका एसएसओ कार्यान्वयन इसका समर्थन करता है तो आपको शायद अपनी वेब सेवाओं को डिज़ाइन करने के अलावा पूरी तरह से कुछ नहीं करना पड़ेगा।
गुड लक
मान लिया जाये कि इन वेब अनुप्रयोगों कर रहे हैं - आप अनुप्रयोगों के बीच साझा विश्वास मॉडल के कुछ प्रकार को लागू करना चाहिए।
किसी भी परिस्थिति में आप अपना खुद का लिखना चाहिए। इसे पेंच करना बहुत आसान है और इसमें से चुनने के लिए बहुत सारे मौजूदा (खुले और वाणिज्यिक दोनों) हैं।
यहां विकल्पों निम्नलिखित हैं: 1 - सभी विंडोज चल रहा है - तुम सिर्फ विंडोज मूल निवासी प्रमाणीकरण (उर्फ SPNEGO) 2 सकता है - आप एसएसओ प्रणाली के कुछ प्रकार लागू कर सकते हैं।लोकप्रिय प्रणाली सीएएस, ओरेकल एक्सेस मैनेजर, सीए साइटमाइंडर, सन एसएसओ और आईबीएम टिवोली एक्सेस मैनेजर हैं। जबकि सीएएस ओपन-सोर्स है, अन्य लोग आपको प्राधिकरण को भी लागू करने की अनुमति देंगे, जबकि सीएएस केवल प्रमाणीकरण करता है।
अंत में - सुनिश्चित करें कि आप जो भी विकल्प चुनते हैं - यह आपकी भाषा के मूल प्रमाणीकरण & प्रमाणीकरण ढांचे के साथ एकीकृत करता है। जावा में यह जैस होगा। .NET में यह .NET सुरक्षा ढांचा होगा। PHP/पर्ल के लिए - आप अपाचे मॉड्यूल का लाभ उठा सकते हैं। लाभ यह है कि आपको सुरक्षा विशेषज्ञ बनने की ज़रूरत नहीं है और यह आपके ऐप को फिर से कोड किए बिना प्रमाणीकरण & प्रमाणीकरण के लिए बाहरी सिस्टम का उपयोग करना आसान बना देगा।
आप एक सार्वजनिक कुंजी प्रमाणीकरण योजना का उपयोग कर सकते हैं।
सार्वजनिक और निजी कुंजी (जावा की कीटोल, जीएनयू जीपीजी या एक समान उपकरण का उपयोग करके) के साथ एक कीपैयर बनाएं। एप्लिकेशन ए पर जानकारी के एक टुकड़े (उदाहरण के लिए एक उपयोगकर्ता नाम) पर हस्ताक्षर करने के लिए निजी कुंजी का उपयोग करें और एप्लिकेशन ए से सुलभ एप्लिकेशन बी के लिए एक लिंक बनाएं और हस्ताक्षरित डेटा शामिल है। एप्लिकेशन बी तब उपयोगकर्ता कुंजी को सत्यापित करने के बाद उपयोगकर्ता को लॉग ऑन कर सकता है कि अनुरोध वास्तव में एप्लिकेशन ए से आया था (जो स्ट्रिंग को डिक्रिप्ट करने में सक्षम है)।
आप निश्चित रूप से दूसरी तरफ नेविगेट करने के लिए एक विपरीत कीपैयर बना सकते हैं, या आप केवल सार्वजनिक कुंजी का उपयोग कर सकते हैं और इसे गुप्त रख सकते हैं (प्रभावी रूप से इसे साझा-गुप्त प्रणाली बनाते हैं)।
यदि उपयोगकर्ता सीधे एप्लिकेशन बी तक पहुंचने का प्रयास करता है तो आप उसे एप्लिकेशन ए पर रीडायरेक्ट कर सकते हैं जो कहता है कि वह एप्लिकेशन बी (या रेफरर चेक करें) से आया है। यदि वह एप्लिकेशन पर पहले ही लॉग ऑन है, तो हस्ताक्षरित डेटा के साथ लिंक बनाएं और उसे रीडायरेक्ट करें, अन्यथा उसे लॉगऑन स्क्रीन के साथ प्रस्तुत करें और लॉगऑन के बाद रीडायरेक्ट करें।
आशा है कि मदद करता है!