क्या कोई व्यक्ति यह समझा सकता है कि नए ASP.NET आइडेंटिटी कोर में दावा तंत्र का क्या मतलब है?
जैसा कि मैं देख सकता हूं, एक AspNetUserLoginsमेज है, जिसमें सम्मिलित है UserId, LoginProviderऔर ProviderKey।
लेकिन, मुझे अभी भी समझ नहीं आ रहा है कि डेटा को AspNetUserClaimsतालिका में कब जोड़ा जाए और इस तालिका का उपयोग किन स्थितियों के लिए किया जाए?
जवाबों:
नए ASP.NET पहचान कोर में दावा तंत्र का क्या मतलब है?
भूमिका और दावा पर आधारित दो सामान्य प्राधिकरण दृष्टिकोण हैं।
भूमिका आधारित सुरक्षा
उपयोगकर्ता को एक या एक से अधिक भूमिकाएं सौंपी जाती हैं, जिसके माध्यम से उपयोगकर्ता को अधिकार प्राप्त होते हैं। साथ ही, उपयोगकर्ता को किसी भूमिका को सौंपने से, उपयोगकर्ता को तुरंत उस भूमिका के लिए परिभाषित सभी एक्सेस अधिकार मिल जाते हैं।
दावा-आधारित सुरक्षा
दावों पर आधारित पहचान दावों का समूह है। एक दावा एक बयान है कि एक इकाई (एक उपयोगकर्ता या अन्य अनुप्रयोग) अपने बारे में बनाता है, यह सिर्फ एक दावा है। उदाहरण के लिए एक दावे की सूची में उपयोगकर्ता का नाम, उपयोगकर्ता का ई-मेल, उपयोगकर्ता की आयु, उपयोगकर्ता का प्राधिकरण कार्रवाई के लिए हो सकता है। भूमिका-आधारित सुरक्षा में, एक उपयोगकर्ता सीधे आवेदन के लिए क्रेडेंशियल्स प्रस्तुत करता है। दावे-आधारित मॉडल में, उपयोगकर्ता दावों को प्रस्तुत करता है न कि आवेदन को साख। व्यावहारिक मूल्य का दावा करने के लिए, यह एक इकाई से आता है जो एप्लिकेशन ट्रस्ट करता है।
नीचे दिए गए चरणों का वर्णन उस दावे-आधारित सुरक्षा मॉडल में होता है:
लेकिन, मैं अभी भी किसी भी जानकारी को समझ नहीं पाया और पा सकता हूं, जब डेटा AspNetUserClaims से जुड़ता है और इस तालिका के लिए किन स्थितियों का उपयोग कर रहा है?
जब आप ऐसी स्थिति में होते हैं जहां एक भूमिका-आधारित सुरक्षा का उपयोग नहीं किया जाता है, और आपने दावा-आधारित सुरक्षा का उपयोग करने के लिए चुना है, तो आपको AspNetUserClaims तालिका का उपयोग करने की आवश्यकता होगी। ASP.NET पहचान में दावे का उपयोग कैसे करें, अधिक जानकारी के लिए नीचे दिए गए लिंक देखें।
http://kevin-junghans.blogspot.com/2013/12/using-claims-in-aspnet-identity.html
अपडेट करें
मुझे किस समय भूमिका-आधारित सुरक्षा का उपयोग करना है और दावा-आधारित कब करना है? क्या आप कृपया कुछ उदाहरण लिख सकते हैं?
ऐसी कोई स्पष्ट स्थिति नहीं है जहाँ आप भूमिका-आधारित या दावा-आधारित सुरक्षा का उपयोग न करें या न करें, ऐसे मामले की तरह नहीं जहाँ आप B के बजाय A का उपयोग करेंगे।
लेकिन, दावा-आधारित अभिगम नियंत्रण, मुख्य व्यवसाय तर्क से प्राधिकरण नियमों के बेहतर पृथक्करण की अनुमति देता है। जब प्राधिकरण नियम बदलते हैं, तो मुख्य व्यवसाय तर्क अप्रभावित रहता है। ऐसी स्थितियाँ होंगी जहाँ आप क्लेम-आधारित दृष्टिकोण का उपयोग करना पसंद कर सकते हैं।
कभी-कभी दावों की जरूरत नहीं होती है। यह एक महत्वपूर्ण अस्वीकरण है। आंतरिक अनुप्रयोगों की मेजबानी वाली कंपनियां दावों द्वारा प्रदान किए गए कई लाभों को प्राप्त करने के लिए एकीकृत विंडोज प्रमाणीकरण का उपयोग कर सकती हैं। सक्रिय निर्देशिका उपयोगकर्ता पहचान को संग्रहीत करने का एक बड़ा काम करती है, और क्योंकि Kerberos विंडोज का एक हिस्सा है, आपके अनुप्रयोगों में कोई प्रमाणीकरण तर्क शामिल नहीं है। जब तक आपके द्वारा बनाया गया प्रत्येक एप्लिकेशन एकीकृत विंडोज प्रमाणीकरण का उपयोग कर सकता है, तब तक आप अपनी पहचान यूटोपिया तक पहुंच सकते हैं। हालाँकि, कई कारण हैं जिनकी वजह से आपको विंडोज ऑथेंटिकेशन के अलावा किसी और चीज़ की ज़रूरत पड़ सकती है। आपके पास वे वेब-फेसिंग एप्लिकेशन हो सकते हैं, जो आपके विंडोज डोमेन में उन लोगों द्वारा उपयोग किए जाते हैं जिनके खाते नहीं हैं। दूसरा कारण यह हो सकता है कि आपकी कंपनी का किसी दूसरी कंपनी में विलय हो गया है और आप ' दो विंडोज जंगलों को प्रमाणित करने में परेशानी हो रही है जो विश्वास नहीं करते हैं (और शायद कभी नहीं)। शायद आप किसी अन्य कंपनी के साथ पहचान साझा करना चाहते हैं जिसके पास गैर- नेट फ्रेमवर्क एप्लिकेशन हैं या आपको विभिन्न प्लेटफार्मों पर चल रहे अनुप्रयोगों (उदाहरण के लिए, मैकिन्टोश) के बीच पहचान साझा करने की आवश्यकता है। ये कुछ ही स्थितियाँ हैं जिनमें दावों पर आधारित पहचान आपके लिए सही विकल्प हो सकती है।
अधिक जानकारी के लिए, कृपया http://msdn.microsoft.com/en-us/library/ff359101.aspx पर जाएँ
The user presents the credentials to the issuing authority that the RP application trusts.आप इस प्राधिकरण / जारीकर्ता के रूप में क्या उपयोग कर सकते हैं? कुछ उदाहरण अच्छे होंगे। मैं एमएसडीएन साइट (आपके द्वारा दिए गए लिंक) पर लेख को लाल कर देता हूं, लेकिन वे केवल एक उदाहरण को सूचीबद्ध करते हैं: एडीएफएस, क्या कोई अन्य विकल्प हैं? यह जानकारी कहीं भी नहीं मिल सकती। :(
बस @Lin ने ऊपर जो कहा है उस पर और अधिक जोड़ना है। मैं विशेष रूप से प्रश्न का उल्लेख कर रहा हूं:
मुझे किस समय भूमिका-आधारित सुरक्षा का उपयोग करना है और दावा-आधारित कब करना है? क्या आप कृपया कुछ उदाहरण लिख सकते हैं?
ऐसे मामले पर विचार करें जहां आपके पास एक क्लॉकिंग सिस्टम है जहां आपके पास एक तकनीशियन और एक प्रबंधक है। हर हफ्ते के अंत में, तकनीशियन को उस सप्ताह के लिए काम करने वाले कारीगरों के काम के घंटे दिखाने वाली सूचनाओं के साथ रिपोर्ट की व्यवस्था करनी चाहिए, जिसे समेकित किया जाता है और पेरोल द्वारा उपयोग किया जाता है। अंतिम रिपोर्ट प्रस्तुत करने से पहले ऐसी प्रणालियों में अक्सर संशोधन या सुधार करना पड़ता है, क्योंकि आप अपने कर्मचारियों को अधिक भुगतान या भुगतान नहीं करना चाहते हैं। आप एक का उपयोग कर सकते Role-Basedएक बनाने के द्वारा प्रबंधक और तकनीशियन के लिए दृष्टिकोण Manager Roleऔर Technician Role। लेकिन यह Manager Roleकारीगरों की घड़ी की जानकारी तक पहुंचने और संपादित करने की क्षमता वाला एक है। दूसरी ओर, आप कर सकते हैंTechnician Roleइन क्षमताओं के बिना उस जानकारी तक पहुँचने के लिए। लेकिन यहाँ दिलचस्प हिस्सा है; एक प्रबंधक एक दावा कर सकता है और एक तकनीशियन को क्लॉकिंग सिस्टम तक पहुंचने और रिपोर्ट बनाने की अनुमति दे सकता है। तो एक दावा बिना एडिट के ही एक्सेस के लिए किया जा सकता है या एक्सेस और एडिट क्षमताओं के साथ बनाया जा सकता है।
यह कहना अधिक पसंद है, ठीक है, डिफ़ॉल्ट रूप से प्रबंधक के रूप में मैं कुछ जानकारी का उपयोग कर सकता हूं जो मेरे तकनीशियन तक नहीं पहुंच सकते हैं। लेकिन मैं हमेशा कार्यालय के आसपास नहीं हूं? मैं ऐसा क्या कर सकता हूं कि वह तब भी काम कर सकता है जब मैं आसपास नहीं हूं? इसे हल करने के लिए सिस्टम में प्रबंधकों के लिए कुछ विशिष्ट जानकारी तक पहुंच के बिना लोगों के लिए दावे बनाने की सुविधा हो सकती है। हम अक्सर अपने ईआरपी सिस्टम में हर जगह इन्हें देखते हैं। कुछ मॉड्यूल तक पहुंच के बिना एक उपयोगकर्ता और जब वे पदोन्नत हो जाते हैं तो वे ईआरपी सिस्टम के अधिक मॉड्यूल की अनुमति दे रहे हैं, कभी-कभी एक ही उपयोगकर्ता भूमिका रखते हैं।
यह एक उदाहरण है जिसे आप दावों और भूमिकाओं को अधिक समझने के लिए सोच सकते हैं।
ASP.Net पहचान में प्रमाणीकरण दो प्रकार के होते हैं।
आप या तो एक ही समय में या दोनों का उपयोग कर सकते हैं। भूमिका का उपयोग तब करें जब आपके पास बहुत परिभाषित चीजें हों। उदाहरण के लिए आप दो राउल टीचर और स्टूडेंट बनाते हैं। केवल शिक्षक ही विषयों को जोड़ सकते हैं। इसलिए आपने उन उपयोगकर्ताओं को शिक्षक की भूमिका सौंपी है, जिनकी आप विषय जोड़ना चाहते हैं।
दावा आधारित अधिक लचीला है। मान लें कि आपके पास एक आवश्यकता है कुछ छात्र विषयों को भी जोड़ सकते हैं। इस मामले में आपको एक और भूमिका बनानी होगी जो छात्र और विषय को जोड़ने के लिए उपयोग कर सकता है। लेकिन अगर आप दावे का उपयोग कर रहे हैं तो यह बहुत आसान होगा। AddSubject जैसा दावा करें और इसे किसी भी उपयोगकर्ता को असाइन करें जिसे आप aubject जोड़ना चाहते हैं।