माइक्रोसर्विसेज में प्रमाणीकरण (Authentication) की गहराई में जानकारी

प्रमाणीकरण सेवा क्या है

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

यह लेख पारंपरिक प्रमाणीकरण और माइक्रोसर्विस प्रमाणीकरण की तुलना करेगा। और आर्किटेक्चर में परिवर्तन के कारण प्रमाणीकरण में आए परिवर्तनों को प्रदर्शित करेगा। अंत में, हम माइक्रोसर्विस आर्किटेक्चर में विभिन्न प्रमाणीकरण सेवाओं और उनके कार्यान्वयन में उनके फायदे और नुकसान का विश्लेषण करेंगे।

पारंपरिक आर्किटेक्चर में प्रमाणीकरण सेवा

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

एक मोनोलिथिक एप्लिकेशन एक अविभाज्य इकाई से बना होता है। इसे आमतौर पर अलग-अलग व्यवसाय लाइनों द्वारा स्वतंत्र रूप से विकसित किया जाता है और तैनाती के समय एक ही वातावरण में संयोजित किया जाता है। ये सभी एक इकाई में सभी कार्यक्षमताएं प्रदान करने के लिए कसकर एकीकृत होते हैं। इस इकाई में सभी आवश्यक संसाधन होते हैं। मोनोलिथिक एप्लिकेशन का फायदा यह है कि इसे तैनात करना और इसमें परिवर्तन करना आसान है। यह कम व्यवसाय लाइनों वाले अधिक स्वतंत्र कंपनियों के लिए उपयुक्त है।

जैसे-जैसे उद्यमों द्वारा विकसित व्यवसाय अधिक जटिल होते जाते हैं, हम पाएंगे कि एकल सेवाएं वास्तविक जीवन में तेजी से परिवर्तन की आवश्यकताओं को पूरा नहीं कर सकती हैं। हमें इस विशाल सिस्टम को विभाजित करने और यह सुनिश्चित करने की आवश्यकता है कि मौजूदा कार्यों के बीच कॉल सामान्य रूप से किए जा सकें। इस समस्या को हल करने के लिए, ESB (एंटरप्राइज सर्विस बस) अस्तित्व में आई।

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

ESB ने अनुरोधों का अनुवाद और रूटिंग किया है ताकि विभिन्न सेवाएं आपस में संचार कर सकें। पारंपरिक ESB सेवा आह्वान विधि यह है कि हर बार कॉलर को पहले केंद्रीय ESB के माध्यम से सेवा तक रूट किया जाना चाहिए।

मोनोलिथिक आर्किटेक्चर

उपयोगकर्ता प्रमाणीकरण और सत्र प्रबंधन अपेक्षाकृत सरल है: प्रमाणीकरण और प्राधिकरण एक ही एप्लिकेशन में होते हैं, आमतौर पर सत्र-आधारित प्रमाणीकरण योजना का उपयोग किया जाता है। एक बार प्रमाणीकरण हो जाने के बाद, एक सत्र बनाया जाता है और सर्वर पर संग्रहीत किया जाता है। कोई भी घटक इसे एक्सेस कर सकता है और इसका उपयोग करके बाद के अनुरोधों को सूचित और प्राधिकृत कर सकता है। सत्र ID क्लाइंट को भेजी जाती है और इसका उपयोग सभी बाद के अनुरोधों को वर्तमान सत्र से जोड़ने के लिए किया जाता है।

ESB आर्किटेक्चर

ESB आर्किटेक्चर के तहत, सेवाओं के बीच सभी प्रक्रियाएं ESB बस के माध्यम से संसाधित की जाती हैं। चूंकि ESB आर्किटेक्चर मोनोलिथिक आर्किटेक्चर से व्युत्पन्न होता है, इसलिए प्रमाणीकरण विधि मोनोलिथिक आर्किटेक्चर की तुलना में नहीं बदली है।

माइक्रोसर्विस आर्किटेक्चर में प्रमाणीकरण सेवा

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

हम माइक्रोसर्विस आर्किटेक्चर के तहत प्रमाणीकरण सेवाओं को निम्नलिखित तीन श्रेणियों में विभाजित कर सकते हैं:

1. प्रत्येक माइक्रोसर्विस पर प्रमाणीकरण लागू करें
2. एक प्रमाणीकरण सेवा के माध्यम से प्रमाणीकरण लागू करें
3. API गेटवे के माध्यम से प्रमाणीकरण लागू करें

प्रत्येक दृष्टिकोण के अपने विशिष्ट फायदे और नुकसान हैं।

प्रत्येक माइक्रोसर्विस पर प्रमाणीकरण लागू करें

चूंकि प्रत्येक माइक्रोसर्विस मोनोलिथिक आर्किटेक्चर से विभाजित होता है, इसलिए प्रमाणीकरण लागू करने के लिए एक प्राकृतिक संक्रमण यह है कि प्रत्येक माइक्रोसर्विस इसे स्वयं लागू करे।

प्रत्येक माइक्रोसर्विस को अपनी स्वतंत्र सुरक्षा गारंटी लागू करनी होगी, जो प्रत्येक प्रवेश बिंदु पर लागू होती है। यह दृष्टिकोण माइक्रोसर्विस टीमों को अपनी सुरक्षा समाधान लागू करने के बारे में स्वायत्त निर्णय लेने का अधिकार देता है। हालांकि, इस दृष्टिकोण के कई नुकसान हैं:

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

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

फायदे: तेजी से कार्यान्वयन, मजबूत स्वतंत्रता

नुकसान: सेवाओं के बीच कोड डुप्लिकेशन; एकल जिम्मेदारी सिद्धांत का उल्लंघन; रखरखाव में कठिनाई

एक प्रमाणीकरण सेवा के माध्यम से प्रमाणीकरण लागू करें

चूंकि प्रत्येक माइक्रोसर्विस के लिए स्वयं प्रमाणीकरण लागू करना मुश्किल है, और एक साझा प्रमाणीकरण लाइब्रेरी का उपयोग करना माइक्रोसर्विस विभाजन के मूल इरादे का उल्लंघन करता है, क्या साझा प्रमाणीकरण लाइब्रेरी को एक समर्पित प्रमाणीकरण सेवा में अपग्रेड किया जा सकता है?

इस मामले में, सभी पहुंच एक ही सेवा द्वारा नियंत्रित होती है, जो मोनोलिथिक एप्लिकेशन में प्रमाणीकरण फ़ंक्शन के समान है। प्रत्येक व्यवसाय सेवा को कोई ऑपरेशन करते समय एक्सेस कंट्रोल मॉड्यूल को एक अलग प्राधिकरण अनुरोध भेजना होगा।

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

फायदे: प्रत्येक माइक्रोसर्विस की एकल जिम्मेदारी होती है, और प्रमाणीकरण केंद्रीकृत होता है

नुकसान: एकल बिंदु विफलता; अनुरोध विलंब में वृद्धि

API गेटवे के माध्यम से प्रमाणीकरण लागू करें

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

क्योंकि सभी अनुरोधों को पहले API गेटवे से गुजरना होता है, यह प्रमाणीकरण मुद्दों को लागू करने के लिए एक उत्कृष्ट उम्मीदवार है। यह विलंब (प्रमाणीकरण सेवाओं के कॉल) को कम करता है और यह सुनिश्चित करता है कि प्रमाणीकरण प्रक्रिया एप्लिकेशन में सुसंगत हो।

उदाहरण के लिए, APISIX के jwt-auth प्लगइन का उपयोग करके, हम गेटवे पर प्रमाणीकरण लागू कर सकते हैं।

1. हमें APISIX पर कई उपयोगकर्ता पहचान जानकारी (नाम, कुंजी, आदि) कॉन्फ़िगर करनी होगी।
2. दिए गए उपयोगकर्ता की कुंजी के अनुसार, APISIX को एक हस्ताक्षर अनुरोध प्रारंभ करें ताकि उपयोगकर्ता का JWT टोकन प्राप्त हो सके।
3. फिर, जब क्लाइंट को एक अपस्ट्रीम सेवा तक पहुंच की आवश्यकता होती है, तो यह JWT टोकन लाता है, और APISIX API गेटवे के रूप में इस पहुंच को प्रॉक्सी करता है।
4. अंत में, APISIX JWT टोकन का उपयोग करके प्रमाणीकरण ऑपरेशन पूरा करेगा।

बेशक, हर चीज के फायदे और नुकसान होते हैं, और कोई भी तकनीक बिना कमियों के पूरी नहीं होती है। API गेटवे का उपयोग करके प्रमाणीकरण पूरा करने में अभी भी कुछ समस्याएं हैं। गेटवे पर इस समस्या को हल करना प्रत्येक माइक्रोसर्विस के भीतर प्रमाणीकरण पूरा करने की तुलना में कम सुरक्षित है। उदाहरण के लिए, यदि API गेटवे समझौता हो जाता है, तो यह इसके पीछे सभी माइक्रोसर्विसेज को उजागर कर देगा। लेकिन जोखिम सापेक्ष है। एकल प्रमाणीकरण सेवा की तुलना में, API गेटवे का उपयोग करने की समस्या हल्की है।

फायदे: बैकएंड माइक्रोसर्विसेज की प्रभावी सुरक्षा; माइक्रोसर्विसेज को किसी भी प्रमाणीकरण तर्क को संभालने की आवश्यकता नहीं होती है

नुकसान: एकल बिंदु विफलता

सारांश

विभिन्न परिदृश्यों में, हमें विभिन्न प्रमाणीकरण योजनाओं की आवश्यकता होगी। एक मोनोलिथिक एप्लिकेशन में, प्रमाणीकरण एक ही एप्लिकेशन के भीतर होता है, और सर्वर सभी सत्रों को सहेजता है। माइक्रोसर्विसेज के युग में, मोनोलिथिक एप्लिकेशन वितरित सेवाओं में विकसित हो गए हैं, और पारंपरिक प्रमाणीकरण विधियां लागू नहीं होती हैं। माइक्रोसर्विस आर्किटेक्चर में, हमारे पास चुनने के लिए तीन प्रमाणीकरण विधियां हैं:

1. प्रत्येक माइक्रोसर्विस पर प्रमाणीकरण लागू करें
2. एक प्रमाणीकरण सेवा के माध्यम से प्रमाणीकरण लागू करें
3. API गेटवे के माध्यम से प्रमाणीकरण लागू करें

प्रत्येक विकल्प के अपने फायदे और नुकसान हैं, जिनका विस्तार से विश्लेषण करने की आवश्यकता है।