API7 Enterprise v3.2.15: मल्टी-क्रेडेंशियल प्रमाणीकरण

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

API7 Enterprise v3.2.15 मौजूदा उपभोक्ता प्रमाणीकरण तंत्र को बढ़ाता है। यह सामान्यतः उपयोग किए जाने वाले प्लगइन्स की बातचीत को अनुकूलित करता है, अनुमति नियंत्रण में सुधार करता है, और प्रति प्लगइन कई प्रमाणीकरण क्रेडेंशियल्स का समर्थन करता है। यह अधिक लचीला क्रेडेंशियल प्रबंधन और रोटेशन सक्षम करता है।

अनुकूलित उपभोक्ता प्रमाणीकरण प्लगइन इंटरैक्शन

आप एक ही प्रमाणीकरण प्लगइन में कई प्रमाणीकरण क्रेडेंशियल्स आसानी से जोड़ सकते हैं। कॉन्फ़िगरेशन को कोडिंग से सहज फॉर्म ऑपरेशन में अपग्रेड किया गया है, जिससे कॉन्फ़िगरेशन प्रक्रिया सरल हो गई है।

वर्तमान में, उपभोक्ता निम्नलिखित चार प्रमाणीकरण विधियों का समर्थन करता है, जिनमें कई क्रेडेंशियल्स शामिल हैं।

कुंजी प्रमाणीकरण

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

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

बेसिक प्रमाणीकरण

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

रूट या सेवा कॉन्फ़िगरेशन में, बेसिक प्रमाणीकरण प्लगइन को सक्षम करने की आवश्यकता होती है, जिसमें प्रमाणीकरण जानकारी को मान्य करने के लिए उचित नियम होते हैं। गेटवे जांचता है कि अनुरोध में Authorization हेडर है और यह बेसिक प्रमाणीकरण प्रारूप का पालन करता है। प्रारूप Basic <encoded-value> है, जहां <encoded-value> उपयोगकर्ता नाम और पासवर्ड को कोलन से अलग करके Base64-एन्कोडेड परिणाम है। गेटवे इस मान को डिकोड करता है और डिकोडेड उपयोगकर्ता नाम और पासवर्ड की तुलना कॉन्फ़िगर की गई जानकारी से करता है। यदि वे मेल खाते हैं, तो अनुरोध को बैकएंड सेवा तक पहुंचने की अनुमति दी जाती है; यदि नहीं, तो अनुरोध अस्वीकार कर दिया जाता है।

ध्यान दें कि बेसिक प्रमाणीकरण उपयोगकर्ता नाम और पासवर्ड को सादे पाठ में प्रसारित करता है, केवल Base64 में एन्कोडेड (एन्क्रिप्टेड नहीं), जो इसे उच्च-सुरक्षा परिदृश्यों के लिए अनुपयुक्त बनाता है।

JWT प्रमाणीकरण

JWT प्रमाणीकरण JSON Web Tokens (JWT) पर आधारित एक विधि है। उपभोक्ताओं को अपने अनुरोधों में एक वैध JWT टोकन शामिल करना चाहिए, जो आमतौर पर Authorization हेडर में Bearer <token> प्रारूप में होता है, लेकिन आवश्यकतानुसार क्वेरी स्ट्रिंग पैरामीटर्स या कुकीज़ में भी रखा जा सकता है। उपभोक्ताओं को अनुरोधों को कॉन्फ़िगर करते समय JWT टोकन की शुद्धता और वैधता सुनिश्चित करनी चाहिए।

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

HMAC प्रमाणीकरण

HMAC प्रमाणीकरण Hash-based Message Authentication Code (HMAC) पर आधारित एक विधि है। उपभोक्ताओं को अनुरोध के लिए एक HMAC मान उत्पन्न करने की आवश्यकता होती है, जो आमतौर पर एक पूर्व-साझा कुंजी और अनुरोध के विशिष्ट भागों (जैसे अनुरोध विधि, URI, अनुरोध बॉडी) का उपयोग करके गणना की जाती है। यह HMAC मान क्वेरी स्ट्रिंग पैरामीटर्स या HTTP हेडर में शामिल किया जा सकता है।

अनुरोधों को कॉन्फ़िगर करते समय, उपभोक्ताओं को निर्दिष्ट एल्गोरिदम और प्रारूप के अनुसार HMAC मान को सही ढंग से उत्पन्न और शामिल करना चाहिए। विशेष रूप से, उपभोक्ताओं को एक ज्ञात कुंजी और अनुरोध जानकारी का उपयोग करके हैशिंग एल्गोरिदम (जैसे SHA-256) का उपयोग करके HMAC उत्पन्न करना चाहिए और इसे अनुरोध में जोड़ना चाहिए।

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

सूक्ष्म उपभोक्ता अनुमति नीतियां

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

सारांश

API7 Enterprise के नवीनतम संस्करण में उपभोक्ता प्रमाणीकरण और अनुमति प्रबंधन में प्रमुख सुधार शामिल हैं। यह प्लगइन इंटरैक्शन को अनुकूलित करता है, स्वतंत्र क्रेडेंशियल प्रबंधन सक्षम करता है, कई प्रमाणीकरण विधियों का समर्थन करता है, और उपभोक्ता अनुमति रणनीतियों को परिष्कृत करता है। ये सुधार क्रेडेंशियल प्रबंधन लचीलापन, सिस्टम सुरक्षा, और समग्र उपयोगकर्ता अनुभव को बढ़ाते हैं।

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