माइक्रोस्कोस आर्किटेक्चर में सिंगल साइन-ऑन

Question

मैं एक हरी-फील्ड प्रोजेक्ट तैयार करने की कोशिश कर रहा हूं जिसमें कई सेवाएं (डेटा की सेवा) और वेब-एप्लिकेशन (एचटीएमएल की सेवा) होगी। मैंने सूक्ष्मजीवों के बारे में पढ़ा है और वे अच्छे फिट की तरह दिखते हैं।

समस्या अभी भी है कि एसएसओ को कैसे कार्यान्वित किया जाए। मैं चाहता हूं कि उपयोगकर्ता एक बार प्रमाणीकृत करे और सभी अलग-अलग सेवाओं और अनुप्रयोगों तक पहुंच प्राप्त करे।

मैं कई दृष्टिकोण के बारे में सोच सकते हैं:

1. पहचान सेवा और आवेदन जोड़ें। संसाधनों को संरक्षित करने वाली कोई भी सेवा पहचान सेवा से बात करेगी ताकि यह सुनिश्चित किया जा सके कि उसके पास प्रमाण पत्र मान्य हैं। यदि वे नहीं हैं तो यह प्रमाणीकरण के लिए उपयोगकर्ता को रीडायरेक्ट करेगा।

2. ओपनआईडी जैसे वेब-मानक का उपयोग करें और प्रत्येक सेवा अपनी पहचान को संभालें। इसका मतलब है कि उपयोगकर्ता को व्यक्तिगत रूप से प्रत्येक सेवा/आवेदन को अधिकृत करना होगा, लेकिन इसके बाद यह एसएसओ होगा।

मुझे अन्य विचारों को सुनकर खुशी होगी। यदि एक विशिष्ट पास (जैसे हेरोकू) में एक मालिकाना समाधान है जो स्वीकार्य भी होगा।

Answer 1

मेरे पिछले काम में एक माइक्रोस्कोप आर्किटेक्चर को लागू करते समय हमने फैसला किया कि सबसे अच्छा तरीका # 1 के साथ संरेखण में था, पहचान सेवा जोड़ें और इसके माध्यम से सेवा पहुंच अधिकृत करें। हमारे मामले में यह टोकन के साथ किया गया था। अगर एक प्राधिकरण टोकन के साथ कोई अनुरोध आया तो हम सेवा सेवा के साथ उपयोगकर्ता के सत्र में पहली कॉल होने पर पहचान सेवा के साथ उस टोकन को सत्यापित कर सकते थे। एक बार टोकन को सत्यापित कर लिया गया था, तो इसे सत्र में सहेजा गया था, इसलिए उपयोगकर्ता के सत्र में आने वाली कॉल को अतिरिक्त कॉल करने की आवश्यकता नहीं थी। टोकन को उस सत्र में रीफ्रेश होने की आवश्यकता होने पर आप एक निर्धारित नौकरी भी बना सकते हैं।

इस स्थिति में हम ओएथ 2.0 एंडपॉइंट के साथ प्रमाणीकरण कर रहे थे और टोकन को हमारे डोमेन पर कॉल के लिए HTTP शीर्षलेख में जोड़ा गया था। सभी सेवाओं को उस डोमेन से रूट किया गया था ताकि हम HTTP शीर्षलेख से टोकन प्राप्त कर सकें। चूंकि हम एक ही अनुप्रयोग पारिस्थितिक तंत्र का हिस्सा थे, प्रारंभिक ओएथ 2.0 प्रमाणीकरण उन अनुप्रयोग सेवाओं की सूची देगा जो उपयोगकर्ता अपने खाते के लिए अनुमति दे रहे हैं।

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

हमारी तैनाती वास्तुकला एडब्ल्यूएस वर्चुअल प्राइवेट क्लाउड (वीपीसी) और हमारी अपनी कंपनी के डेटा केंद्रों में फैली हुई थी। ओएथ 2.0 प्रमाणीकरण सेवा कंपनी के डेटा सेंटर में स्थित थी, जबकि हमारी सभी आवेदन सेवाएं एडब्ल्यूएस वीपीसी में तैनात की गई थीं।

मुझे उम्मीद है कि हमने जो दृष्टिकोण लिया है वह आपके निर्णय के लिए सहायक है। अगर आपके पास कोई अन्य सवाल है तो मुझे बताएं।

Answer 2

क्रिस स्टर्लिंग ने मानक प्रमाणीकरण अभ्यास को ऊपर बताया और यह पूर्ण ज्ञान देता है। मैं कुछ व्यावहारिक कारणों के लिए यहां एक और विचार रखना चाहता हूं।

हमने प्रमाणीकरण सेवाओं और संसाधनों को अधिकृत करने के लिए ऑथ सर्वर पर निर्भर कई अन्य माइक्रो सेवाओं को लागू किया। कुछ बिंदु पर हम प्रमाणीकरण सर्वर के लिए कई दौर यात्राओं के कारण प्रदर्शन मुद्दों में भाग गए, हमारे पास ऑथ सर्वर के लिए स्केलेबिलिटी समस्याएं थीं क्योंकि माइक्रो सेवाओं की संख्या में वृद्धि हुई थी। हमने कई गोल यात्रा से बचने के लिए आर्किटेक्चर को थोड़ा सा बदल दिया।

ऑथ सर्वर से केवल एक बार क्रेडेंशियल के साथ संपर्क किया जाएगा और यह एक निजी कुंजी के आधार पर टोकन उत्पन्न करेगा। अनुरूप सार्वजनिक कुंजी प्रत्येक क्लाइंट (माइक्रो सेवा सर्वर) में स्थापित की जाएगी जो ऑथ सर्वर से संपर्क करने के साथ प्रमाणीकरण कुंजी को सत्यापित करने में सक्षम होगी। कुंजी में समय उत्पन्न होता है और माइक्रो सेवा में स्थापित क्लाइंट यूटिलिटी वैधता भी होगी। हालांकि यह मानक कार्यान्वयन नहीं था, लेकिन इस मॉडल के साथ हमें बहुत अच्छी सफलता मिली है, खासकर जब सभी माइक्रो सेवाओं को आंतरिक रूप से होस्ट किया जाता है।