एएसपी.नेट एमवीसी 4 सुरक्षा, प्रमाणीकरण, और प्रमाणीकरण

Question

मैं विजुअल स्टूडियो 2011 बीटा का उपयोग कर एक नई एएसपीएनटी एमवीसी 4 प्रोजेक्ट पर काम कर रहा हूं और पूरी सुरक्षा चीज़ के आसपास अपना सिर लेने की कोशिश कर रहा हूं। यह एक आंतरिक इंट्रानेट एप्लिकेशन है जो प्रारंभ में एकल साइन ऑन का उपयोग करेगा, इसलिए उपयोगकर्ता को विंडोज आईडी/पासवर्ड के लिए संकेत नहीं दिया जाएगा (अभी तक)। कंपनी के पास विभिन्न अनुप्रयोगों के लिए भूमिकाओं को संग्रहित करने के लिए एक कस्टम एप्लिकेशन है और संग्रहीत प्रक्रिया कॉल के माध्यम से उपलब्ध होगा। यह उपयोगकर्ता की लॉगऑन आईडी लेगा और भूमिकाओं सहित कुछ प्रकार के संग्रह को वापस लाएगा। "MyApp.Data", "MyApp.User," MyApp.Admin "। तो इसका क्या अर्थ है - क्या यह एक कस्टम सदस्यता प्रदाता, कस्टम भूमिका प्रदाता या कुछ और है?

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

तो यदि कोई उपयोगकर्ता पहले ही नेटवर्क में साइन इन कर चुका है तो इसका मतलब है कि वे प्रमाणीकृत हैं - सही? अगर ऐसा है तो मुझे केवल प्राधिकरण को लागू करने की आवश्यकता है। क्या प्राधिकरण विशेषता के साथ प्रत्येक नियंत्रक या क्रिया को सजाने के लिए आवश्यक है? यदि ऐसा है तो कैसे [एबीसी "का हिस्सा [प्राधिकरण (भूमिकाएं =" एबीसी ")] सेट है यदि मैं अपने कस्टम रोल स्टोरेज ऐप से भूमिकाएं पुनर्प्राप्त करता हूं?

मैं कई लेख और जॉन गैलोवे से इसे मिलाकर ब्लॉग पोस्ट को पढ़ने, लेकिन मैं अंत में खो गया:

Customizing Authentication and Authorization The Right Way

तो कई सवाल ... किसी को भी कैसे की अच्छी उच्च स्तरीय विवरण के जानता है यह सब एक साथ लटकता है तो मैं सभी कान हूं :)

Answer 1

का एक उदाहरण यह सब कैसे का एक उच्च स्तरीय दृश्य देता है कि लटकी हुई एक साथ होना चाहिए मैंने सोचा कि मैं था अब तक मेरी निष्कर्ष नीचे घसीटना:

• कंपनी, उपयोगकर्ता की दुकान लॉगऑन विवरण के लिए सक्रिय निर्देशिका का उपयोग करता है ताकि इस सदस्यता के लिए प्रयोग किया जाता है मैं एक कस्टम सदस्यता प्रदाता जरूरत नहीं है। एक बार जब उपयोगकर्ता कंपनी नेटवर्क पर लॉग ऑन हो जाता है तो वे प्रमाणीकृत होते हैं। एक वैश्विक प्राधिकरण फ़िल्टर जोड़ना सुनिश्चित करता है कि सिस्टम तक पहुंचने वाले किसी भी उपयोगकर्ता को प्रमाणित करने की आवश्यकता होगी।MSDN पर रिक एंडरसन से तारीख की जानकारी के लिए ऊपर:

  http://blogs.msdn.com/b/rickandy/archive/2012/03/23/securing-your-asp-net-mvc-4-app-and-the-new-allowanonymous-attribute.aspx

तो Global.asax में मैं जोड़ना होगा:

public static void RegisterGlobalFilters(GlobalFilterCollection filters) 
{ 
    filters.Add(new HandleErrorAttribute()); 
    filters.Add(new System.Web.Mvc.AuthorizeAttribute()); //new 
} 

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

• इन 2 मानक भूमिकाओं के साथ-साथ सुपरसियर आदि जैसी भूमिकाएं आवश्यक हैं। इन भूमिकाओं के व्यापार नियमों के आधार पर विभिन्न अधिकार होंगे। और हमारे आवेदन डेटाबेस में संग्रहीत करने की आवश्यकता होगी। तो इस परिदृश्य के लिए मुझे एक कस्टम रोल प्रदाता बनाने की आवश्यकता होगी, मेरे ऐप डेटाबेस में उपयुक्त एएसपीनेट रोल टेबल जोड़ें, और इसे web.config में प्लग करें।

  http://msdn.microsoft.com/en-us/library/9ab2fxh0.aspx

• क्या मैं अब तक केवल टेबल मैं एक कस्टम भूमिका प्रदाता के लिए की जरूरत है पढ़ा है से भूमिकाओं और UsersInRoles हैं: यहाँ एक एमएस प्रबंध प्राधिकरण शीर्षक पृष्ठ भूमिकाओं कि मैं बिट्स उठा रहा हूँ का उपयोग किया जा रहा है ।

  CREATE TABLE भूमिकाओं ( Rolename पाठ (255) नहीं NULL, ApplicationName पाठ (255) नहीं NULL, बाधा PKRoles प्राथमिक कुंजी (Rolename, ApplicationName) )

  CREATE TABLE UsersInRoles ( प्रयोक्ता नाम पाठ (255) नहीं NULL, Rolename पाठ (255) नहीं NULL, ApplicationName पाठ (255) नहीं NULL, बाधा PKUsersInRoles प्राथमिक कुंजी (उपयोगकर्ता नाम, Rolename, ApplicationName) )

• एक बार यह सब सेटअप हो जाने के बाद मुझे यह पता लगाने की आवश्यकता है कि वैश्विक डेटा स्टोर से 2 मानक भूमिकाओं (उपयोगकर्ता और व्यवस्थापक) को मेरे ऐप डेटाबेस में संग्रहीत कस्टम भूमिकाओं के साथ कैसे विलय करना है, और यदि मैं उपयोग कर सकता हूं (उदाहरण के लिए) [ एक नियंत्रक/क्रिया पर प्राधिकरण (भूमिकाएं = "व्यवस्थापक, सुपरसुर")] या अगर मुझे AuthoriseAttribute को उपclass करने और कुछ और चालाक करने की आवश्यकता है।

• मुझे अभी एहसास हुआ कि जब मैं प्रमाणीकरण के लिए एडी का उपयोग करता हूं तो मुझे मौजूदा उपयोगकर्ता के भूमिकाओं के संग्रह को जोड़ने/इंजेक्शन करने का एक तरीका चाहिए। इसलिए हालांकि मुझे किसी कस्टम सदस्यता प्रदाता कार्यक्षमता की आवश्यकता नहीं है, फिर भी मुझे अपनी भूमिका संग्रह को अपडेट करने के लिए httpContext.User से बातचीत करना है।

Answer 2

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

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited=true, AllowMultiple=true)] 
public class CustomAuthorizationAttribute : AuthorizeAttribute 
{ 
    protected override bool AuthorizeCore(HttpContextBase httpContext) 
    {   
     IPrincipal user = httpContext.User; 
     if (!user.Identity.IsAuthenticated) 
     { 
      return false; 
     } 

    //check your users against a database and return true or false 
     return base.AuthorizeCore(httpContext); 
    } 
} 

साथ काम कर रहे तो फिर तुम इस

[CustomAuthorization] 
public ActionResult SomeAction() 
{ 
    return View(); 
} 

अद्यतन की तरह विशेषता का उपयोग कर सकते हैं की जाँच करेगा बनाने

AuthorizeCore वह तरीका है जिसका उपयोग यह जांचने के लिए किया जाएगा कि इस उपयोगकर्ता को संबंधित क्रिया विधि तक पहुंचने की अनुमति दी जानी चाहिए या नहीं। इस विधि के भीतर आप httpContext.User.Identity.Name प्रॉपर्टी को अपने डेटाबेस के विरुद्ध देख सकते हैं या जहां आपकी भूमिकाएं संग्रहीत की जाती हैं। आप सक्रिय निर्देशिका के माध्यम से विंडोज प्रमाणीकरण का उपयोग कर रहे हैं, तो HttpContext.User.Identity एक जवाब के अभाव में ठीक WindowsIdentity

Answer 3

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

आपको कस्टम प्राधिकरण विशेषता की आवश्यकता नहीं है। रोल प्रिंसिपल/रोलप्रोवाइडर आवश्यक भूमिकाएं लाएगा और मानक प्राधिकृत विशेषता के साथ काम करेगा।

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

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

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