जब एसीएस का उपयोग नहीं किया जाता है?

Question

मैं एज़ूर एक्सेस कंट्रोल सर्विस (एसीएस) का शोध कर रहा हूं, और ऐसा लगता है कि यह विषम (कॉन्फ़िगर करने योग्य) पहचान प्रदाताओं से प्रमाणीकरण को संभालने में विशेष रूप से अच्छा है। फिर ऐसे कई अतिरिक्त परिदृश्य हैं जो इसे समर्थन देने के लिए प्रतीत होते हैं (उदाहरण के लिए देखें ACS How-To's)।

मेरे पास जो सवाल है वह विपरीत है: यह वास्तव में इसे समझने में मदद करेगा, इसे ठीक से उपयोग करने के लिए, क्या एसीएस अच्छा नहीं है। एसीएस की सीमाएं क्या हैं, और/या कुछ परिदृश्य क्या हैं जहां एसीएस अनुचित होगा?

(मान लीजिए कि तर्क के लिए, मैं एक लाभदायक बनाने की योजना बना रहा हूं :) - सार्वजनिक वेब एपीआई और संबंधित वेब साइट फ्रंट एंड, जो Azure में होस्ट किया गया है - यानी, मुझे उपयोगकर्ता पहचान की परवाह है। यदि आप चाहें, तो आप आगे यह मान सकते हैं कि मेरा सिस्टम .NET का उपयोग करके बनाया जाएगा।)

धन्यवाद!

Answer 1

आपको एसीएस को पहचान प्रदाता के रूप में उपयोग नहीं करना चाहिए।

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

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

लेकिन एसीएस की क्षमताओं को पूरी तरह से संचालित निर्देशिका, प्रमाणीकरण और प्राधिकरण समाधान जैसे एडी और एडीएफएस के साथ भ्रमित नहीं किया जाना चाहिए। संक्षेप में, एसीएस एडी/एडीएफएस का संस्करण नहीं हो सकता है।

Answer 2

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

उस परिदृश्य की कल्पना करें जहां आपका उपयोगकर्ता आपके यूएसए नेमस्पेस के माध्यम से लॉग इन करता है। आपके आवेदन को उस उपयोगकर्ता के लिए आईडी (हैश) प्राप्त होगा और आप शायद उस एप्लिकेशन के लिए अपने आवेदन में एक प्रोफ़ाइल तैयार करेंगे। एक सप्ताह बाद आपका उपयोगकर्ता यूरोप की यात्रा करता है और आपके यूरोप नेमस्पेस के माध्यम से लॉग इन कर सकता है। भले ही यह वही उपयोगकर्ता है, फिर भी आपको उस उपयोगकर्ता के लिए एक अन्य आईडी (हैश) मिलेगा, ऐसा लगता है कि यह एक नया उपयोगकर्ता है, भले ही यह नहीं है। ऐसा इसलिए है क्योंकि आईडी (हैश) एसीएस नेमस्पेस पर निर्भर करता है।

Quoting an MSFT employee:

यूजर आईडी आप Windows Live ID के लिए एसीएस से प्राप्त करते हैं कि आपकी सेवा नाम स्थान पर है कि उपयोगकर्ता के लिए विशिष्ट हो जाएगा। यदि आप एक अलग सेवा नामस्थान का उपयोग करते हैं, तो आपको उसी उपयोगकर्ता के लिए एक अलग मूल्य मिलेगा। तो आपके सवालों के जवाब: * लैब्स एसीएस और प्रॉड एसीएस [अलग आईडी]

• अलग भरोसा पक्ष अलग-अलग ग्राहकी में (prod में) [विभिन्न आईडी]

• ही सदस्यता में विभिन्न आर पी एस [ एक ही आईडी यदि सेवा नाम स्थान में एक ही, एक ही सदस्यता में 2 नामस्थान]

• के लिए अलग अगर मैं हटा सकते हैं और एक ही दायरे में आरपी के पुनर्निर्माण, एक ही खाते [एक ही आईडी] है

अद्यतन:

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