Product-apim: सब्सक्राइबर्स के लिए बेसिक ऑथेंटिकेशन का समर्थन करें

हाल ही में जारी किया गया APIM 3.0.0 मूल प्रमाणीकरण का समर्थन करता है। वर्तमान में हम इसे अपने परिवेश में उपयोग करते हैं।

हाँ बैकएंड एंडपॉइंट्स के लिए। एपी के लिए मुझे विकल्प नहीं मिला।

एपीआई प्रकाशक -> रनटाइम कॉन्फ़िगरेशन -> एप्लिकेशन स्तर सुरक्षा

@ Tomas-Mrazek सही है, अब हम एपीआई क्लाइंट के लिए भी बेसिक ऑथेंटिकेशन का समर्थन करते हैं। जैसा कि ऊपर दिखाया गया है, आप एप्लिकेशन-स्तरीय सुरक्षा के तहत Basic विकल्प को सक्षम कर सकते हैं। यह एपीआई उपभोक्ताओं को अपने उपयोगकर्ता नाम पासवर्ड संयोजन का उपयोग करके इस एपीआई को लागू करने की अनुमति देगा।

ठीक है, ऐसा लगता है कि मैं उसी जगह को देख रहा था। बस इसका परीक्षण किया और यह काम करता है।

यह और सवाल लाता है।

सदस्यताएँ मूल प्रमाणीकरण के साथ कैसे कार्य करती हैं? ऐसा लगता है कि कोई भी उपयोगकर्ता सदस्यता से स्वतंत्र किसी भी एपीआई का आह्वान कर सकता है? क्या विशिष्ट अनुप्रयोगों के लिए उपयोगकर्ताओं को "असाइन" करने का कोई तरीका है ताकि वे केवल एपीआई का आह्वान कर सकें कि किस एप्लिकेशन की सदस्यता ली गई है?

यदि उत्पाद और सैंडबॉक्स दोनों एक ही गेटवे साझा करते हैं, तो यह कैसे निर्धारित किया जाता है कि मूल प्रमाणीकरण करते समय किसका उपयोग किया जाता है?

यदि हम मूल प्रमाणीकरण में उपयोगकर्ता नाम और पासवर्ड के बजाय एप्लिकेशन कुंजी और एप्लिकेशन सीक्रेट का उपयोग करते हैं तो इन दो प्रश्नों के उत्तर की आवश्यकता नहीं होगी।

शायद मुझे कुछ याद आ रहा है, इसलिए अच्छा होगा अगर आप मुझे दस्तावेज़ीकरण की ओर इशारा कर सकें।

सदस्यताएँ मूल प्रमाणीकरण के साथ कैसे कार्य करती हैं? ऐसा लगता है कि कोई भी उपयोगकर्ता सदस्यता से स्वतंत्र किसी भी एपीआई का आह्वान कर सकता है? क्या विशिष्ट अनुप्रयोगों के लिए उपयोगकर्ताओं को "असाइन" करने का कोई तरीका है ताकि वे केवल एपीआई का आह्वान कर सकें कि किस एप्लिकेशन की सदस्यता ली गई है?

नहीं, इसे oauth2 टोकन की तरह ही काम करना चाहिए। केवल सब्सक्राइब किए गए उपयोगकर्ता ही एपीआई को लागू कर सकते हैं, इससे कोई फर्क नहीं पड़ता कि टोकन या बेसिक ऑथ के माध्यम से।

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

यदि उत्पाद और सैंडबॉक्स दोनों एक ही गेटवे साझा करते हैं, तो यह कैसे निर्धारित किया जाता है कि मूल प्रमाणीकरण करते समय किसका उपयोग किया जाता है?

अच्छा प्रश्न। मुझे जवाब नहीं पता।

वैसे, यह उपभोक्ता कुंजी और रहस्य के साथ काम नहीं करेगा। समापन बिंदु/टोकन पीढ़ी AFAIK के दौरान निर्दिष्ट किया गया है।

हाय @ Tomas-Mrazek और @tmkasun , यह अब मूल प्रमाणीकरण के साथ मेरा मुद्दा है। मुझे प्रमाणीकरण पर अपने विचारों को संक्षेप में प्रस्तुत करने का प्रयास करें:

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

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

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

मूल प्रमाणीकरण का समर्थन करने के "सही" तरीके के रूप में मैं जो देखूंगा वह निम्नलिखित होगा:

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

वहाँ कैसे पहुंचें?

दो विकल्प हैं। या तो वर्तमान मूल कार्यान्वयन को ऊपर प्रस्तावित में बदलें, या "ऐप बेसिक प्रमाणीकरण" नामक एक नया लागू करें।
मौजूदा मूल लेख में उपयोगकर्ता/पास और कुंजी/गुप्त दोनों का समर्थन करने के लिए एक तीसरा विकल्प भी है, लेकिन यह सबसे गंदा है।

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

हाय @ टॉमस-मरेज़ेक और @markokocic
आपके सुझावों के लिए धन्यवाद, कृपया मेरे उत्तर इनलाइन खोजें।

सदस्यताएँ मूल प्रमाणीकरण के साथ कैसे कार्य करती हैं? ऐसा लगता है कि कोई भी उपयोगकर्ता सदस्यता से स्वतंत्र किसी भी एपीआई का आह्वान कर सकता है? क्या विशिष्ट अनुप्रयोगों के लिए उपयोगकर्ताओं को "असाइन" करने का कोई तरीका है ताकि वे केवल एपीआई का आह्वान कर सकें कि किस एप्लिकेशन की सदस्यता ली गई है?

क्लाइंट अनुरोधों के लिए मूल प्रमाणीकरण समर्थन के लिए सदस्यता की उपस्थिति की आवश्यकता नहीं होती है। यदि एक एपीआई निर्माता ने किसी विशेष एपीआई के लिए मूल प्रमाणीकरण समर्थन सक्षम किया है, तो उस एपीआई को उस एपीआई (एप्लिकेशन द्वारा) की सदस्यता के बिना लागू किया जा सकता है।
और @markokocic हाँ, सदस्यता कैसे काम करती है, An Application subscribed to an API ।

इसके अलावा Baisc प्रमाणीकरण के साथ:
आपको अभी भी मिलता है:

• संसाधन स्तर या एपीआई स्तर थ्रॉटलिंग
• संसाधन क्षेत्र सत्यापन

आपको नहीं मिलेगा:

• सदस्यता स्तर थ्रॉटलिंग
• उत्पादन और सैंडबॉक्स पर्यावरण भेदभाव

यदि उत्पाद और सैंडबॉक्स दोनों एक ही गेटवे साझा करते हैं, तो यह कैसे निर्धारित किया जाता है कि मूल प्रमाणीकरण करते समय किसका उपयोग किया जाता है?

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

@ टॉमस-मराज़ेक

समापन बिंदु/टोकन पीढ़ी AFAIK के दौरान निर्दिष्ट किया गया है।

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

@markokocic के बारे में

ऐप-स्तरीय मूल प्रमाणीकरण

यह वर्तमान कार्यान्वयन के साथ भी संभव है। आप एप्लिकेशन स्वामी की ओर से टोकन जोड़ी प्राप्त करने के लिए क्लाइंट क्रेडेंशियल अनुदान प्रकार का उपयोग कर सकते हैं।

ऐप-स्तरीय मूल प्रमाणीकरण

यह वर्तमान कार्यान्वयन के साथ भी संभव है। आप एप्लिकेशन स्वामी की ओर से टोकन जोड़ी प्राप्त करने के लिए क्लाइंट क्रेडेंशियल अनुदान प्रकार का उपयोग कर सकते हैं।

@tmkasun
हां, क्लाइंट क्रेडेंशियल का उपयोग करके टोकन जेनरेट करने के लिए मूल प्रमाणीकरण का उपयोग करना संभव है। आप कुछ इस तरह का उपयोग करते हैं:

curl -k -X POST https://localhost:8243/token -d "grant_type=client_credentials" -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

हालांकि, एपीआई का उपयोग करने के लिए, आपके उपभोक्ता को अभी भी सक्षम होना चाहिए:

• उपरोक्त विधि का उपयोग करके टोकन उत्पन्न करें
• वास्तविक एपीआई अनुरोध के लिए इसे बियरर और टोकन के साथ http "प्राधिकरण" शीर्षलेख के रूप में सेट करें
• अंततः टोकन समाप्ति और ताज़ा करने का ध्यान रखें

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

जो मैंने ऊपर ऐप-लेवल बेसिक ऑथेंटिकेशन के रूप में वर्णित किया है, वह वास्तव में टोकन जेनरेशन के चरण को छोड़ने की क्षमता है, और एपीआई को लागू करने के लिए क्लाइंट क्रेडेंशियल के आधार पर सीधे बेसिक ऑथेंटिकेशन का उपयोग करता है।

कुछ इस तरह:

curl -k -X POST https://localhost:8243/my/nice/Api/doSomething -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

यह मुझे अभी भी उपयोगकर्ताओं को बनाने, सेटअप करने और प्रबंधित करने की आवश्यकता के बिना एक समान तरीके से एपीआई सदस्यता मॉडल के लिए एक ही ऐप का उपयोग करने की अनुमति देगा।

एक अन्य लाभ के रूप में, चूंकि मूल प्रमाणीकरण मानक URL के हिस्से के रूप में प्राधिकरण शीर्षलेख को शामिल करने की क्षमता प्रदान करता है, इसलिए हम कुछ इस तरह से पुराने उपभोक्ताओं का भी समर्थन कर सकते हैं:

curl -k -X POST https://consumer-key:consumer-secret<strong i="25">@localhost</strong>:8243/my/nice/Api/doSomething

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