मैं लगभग यह पता लगा रहा हूं कि प्रमाणीकरण और प्राधिकरण सर्वर आर्किटेक्चर के विभिन्न टुकड़े कैसे काम करते हैं। मुझे सच में लगता है कि पहचान सर्वर सॉफ्टवेयर का एक बड़ा टुकड़ा है।पहचान सर्वर 3 + Asp.net पहचान: स्कोप्स, दावे और ग्राहक - स्पष्टीकरण
मैं अपने प्रश्नों के लिए आधार तय करने के लिए अपनी खोजों को सारांशित करने की कोशिश कर रहा हूं।
- पहचान सर्वर ओपनआईडी कनेक्ट का उपयोग कर टोकन जारी करता है। जारी टोकन आईडी टोकन और एक्सेस टोकन हैं।
- टोकन से अनुरोध किया जाता है - ओपनआईडी कनेक्ट प्रोटोकॉल द्वारा बताए गए अनुसार - ओएथ 2.0 प्रवाह का उपयोग करके ग्राहकों को। प्रत्येक ग्राहक के लिए एक प्रवाह।
- प्रवाह शुरू होने के दौरान, क्लाइंट स्कोप का संग्रह (कम से कम "ओपनिड" का अनुरोध करता है, ऐसा इसलिए है क्योंकि उसे यह कहना है कि एक ओपनआईडी कनेक्ट प्रवाह सक्रिय किया गया है)
- कोई ग्राहक उन सभी क्षेत्रों से पूछ सकता है जिन्हें वह अधिकृत है पूछना। पहचान सर्वर के लिए इकाई फ्रेमवर्क प्लगइन का उपयोग करके, यह जानकारी क्लाइंटस्कोप तालिका में निहित है। यदि ग्राहक एक दायरे का अनुरोध करता है कि वह अनुरोध करने के लिए अधिकृत नहीं है, तो प्रवाह बाधित है।
- स्कॉप्स में "दावे" हो सकते हैं। इसका अर्थ यह है कि यदि किसी दायरे में दावों का समूह होता है, जब भी ग्राहक को टोकन जारी किया जाता है, तो इस टोकन में सभी संबंधित उपयोगकर्ता के दावे भी होते हैं। उदाहरण के लिए: "भूमिका" को एक ऐसे दायरे को कॉल करने दें जिसमें "भूमिका" दावा शामिल है। जैसे ही ग्राहक अधिकृत होता है, प्राप्त टोकन में सभी उपयोगकर्ता की भूमिकाएं (दावे के रूप में) शामिल होंगी।
- प्रत्येक अनुरोधित दायरे, यदि अधिकृत है, तो "स्कोप" नाम के दावे में "अनुवादित" है। इसका अर्थ यह है कि यदि कोई क्लाइंट अनुरोध करता है, उदाहरण के लिए, एक परिभाषित "एपीआई" दायरा, जेनरेट की गई पहचान कम से कम "दायरा" नामक दावे "एपीआई" के साथ दावा करेगी।
अगर मैं क्या लिखा है के सभी अधिक और कम सही है, यहाँ मेरे सवालों हैं:
- कैसे दावों asp.net पहचान तालिकाओं (यानी AspNetUserClaims) IdentityServer लोगों से जुड़ा पर परिभाषित कर रहे हैं । मैंने जो देखा है उसके लिए नाम पर बनाया गया है। क्या यह निष्कर्ष सही है? दूसरे शब्दों में, यदि मेरे क्लाइंट को "भूमिका" दावों को प्राप्त करना है (क्योंकि उन्होंने "भूमिकाएं" दायरे के लिए कहा है), तो पहचानकर्ता सर्वर के लिए "Asp.Net Identity" प्लगइन केवल प्रमाणीकृत के लिए परिभाषित "भूमिका" दावों को छोड़ देगा उपयोगकर्ता?
- "EntityFramework" प्लगइन टेबल का संदर्भ देने, "क्लाइंटक्लेम" तालिका का अर्थ क्या है? मैं नहीं समझ सकता कि दावों को सीधे क्लाइंट से कैसे जोड़ा जा सकता है ... मुझे क्या याद आ रही है?
मान लेते हैं कि मेरी संसाधन सर्वर में मैं एक कार्य इस तरह की एक ResourceAuthorize विशेषता के साथ सुरक्षित की है:
[ResourceAuthorize ("पढ़ें", "आदेश")]
मेरी AuthorizationManager में मैं के लिए जाँच दावा "ऑर्डर_read" या दावा "एपीआई" की उपस्थिति। वे मेरे प्राधिकरण सर्वर में परिभाषित दो अलग-अलग स्कोप हैं, केवल एक "ऑर्डर रीडिंग" के लिए और एक पूर्ण एपीआई एक्सेस के लिए अंतिम। पहले तीसरे पक्ष के ग्राहकों द्वारा पूछा जा सकता है, जबकि बाद वाला नंबर। क्या यह एक अच्छा अभ्यास है?
मुझे समझ में नहीं आता कि मेरे क्लाइंट को id_token के साथ क्या करना चाहिए। क्या मुझे समस्या को अनदेखा करना चाहिए, क्योंकि मैं जेएस लाइब्रेरी ओआईडीसी टोकन मैनेजर का उपयोग कर रहा हूं? क्या इस पुस्तकालय द्वारा सुरक्षा नियंत्रण किया जाता है?
- अंतिम प्रश्न: जब मेरा एप्लिकेशन एक्सेस टोकन प्रस्तुत करता है, तो दावों की उत्पत्ति कैसे उत्पन्न होती है? यह कहने का अधिकार है कि यह पहचान सर्वर पर टोकन को सत्यापित करने के बाद उत्पन्न हुआ है?क्या इसका मतलब है कि पहचान सर्वर को टोकन का उपयोग मिलेगा और दावों के एक सेट में इसका अनुवाद होगा?
आपकी स्पष्टीकरण के लिए धन्यवाद!
मार्को
अरे, आपकी प्रतिक्रिया के लिए धन्यवाद! मैं वास्तव में इसकी प्रशंसा करता हूँ! 1. हाँ, मैं समझता हूं कि पहचान प्रबंधन पुस्तकालय पर कोई जनादेश नहीं है। मैं बस सोच रहा था कि स्कॉप्स के तहत परिभाषित "अनुरोधित" दावों को एएसपीनेट पहचान दावों में कैसे मैप किया गया है। मैंने जो देखा है उसके लिए यह मानचित्रण सिर्फ नाम पर किया गया है। सही बात? 2. मुझे वास्तव में id_token की भावना नहीं मिल सकती है ... क्या आपके पास कोई संसाधन है जहां मैं बेहतर समझ सकता हूं? 3. ठीक है! वही तो में सोच रहा था। 4. ग्राहक दावा: इसलिए यदि मैं चाहता हूं कि ग्राहक के पास हमेशा कुछ दावे हों, भले ही वे अनुरोधित क्षेत्रों में शामिल न हों? 5. ठीक है! – Marconline