बिजनेस लेयर सुरक्षित का एक तरीका बनाएं। सर्वोत्तम अभ्यास/सर्वोत्तम पैटर्न

Question

हम बहुत से AJAX "पेज विधि" कॉल के साथ ASP.NET का उपयोग कर रहे हैं। पृष्ठ में परिभाषित वेब सर्विसेज हमारे BusinessLayer से विधियों को आमंत्रित करता है। हैकर्स को पेज विधियों को कॉल करने से रोकने के लिए, हम BusinessLayer में कुछ सुरक्षा लागू करना चाहते हैं।

हम दो अलग-अलग मुद्दों से जूझ रहे हैं।

पहले एक:

public List<Employees> GetAllEmployees() 
{ 
    // do stuff 
} 

इस विधि भूमिका "मानव संसाधन" के साथ अधिकृत उपयोगकर्ताओं द्वारा बुलाया जाना चाहिए।

दूसरा एक:

public Order GetMyOrder(int orderId) 
{ 
    // do sutff 
} 

यह पद्धति केवल आदेश के मालिक द्वारा बुलाया जाना चाहिए।

मैं जानता हूँ कि यह कैसा प्रत्येक विधि के लिए सुरक्षा लागू करने के लिए आसान है:

public List<Employees> GetAllEmployees() 
{ 
    // check if the user is in Role HR 
} 

या

public Order GetMyOrder(int orderId) 
{ 
    // check if the order.Owner = user 
} 

क्या मैं के लिए देख रहा हूँ कुछ पैटर्न/सबसे अच्छा सुरक्षा के इस प्रकार लागू करने के लिए अभ्यास है एक सामान्य तरीके से (अगर हर बार कोडिंग किए बिना) मुझे आशा है कि आपको मेरा मतलब मिल जाएगा :-)

Answer 1

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

[PrincipalPermission(SecurityAction.Demand, Role="HR")] 
public List<Employees> GetAllEmployees() 
{ 
    // do stuff 
} 

PrincipalPermissionAttribute System.Security.Permissions नाम स्थान का हिस्सा है और नेट (.NET के बाद से 1.0) का हिस्सा है। मैं अपने वेब अनुप्रयोगों में भूमिका आधारित सुरक्षा को लागू करने के लिए पहले से ही वर्षों से इसका उपयोग कर रहा हूं। इस विशेषता के बारे में अच्छी बात यह है कि .NET JIT संकलक पृष्ठभूमि पर आपके लिए सभी बुनाई करता है और आप इसे कक्षा स्तर पर भी परिभाषित कर सकते हैं। उस स्थिति में उस प्रकार के सभी सदस्यों को उस विशेषता और इसकी सुरक्षा सेटिंग्स का उत्तराधिकारी होगा।

बेशक इसकी सीमाएं हैं। आपका दूसरा कोड नमूना .NET भूमिका आधारित सुरक्षा विशेषता का उपयोग करके लागू नहीं किया जा सकता है। मुझे लगता है कि आप वास्तव में इस विधि में कुछ कस्टम सुरक्षा जांच के आसपास नहीं आ सकते हैं, या कुछ आंतरिक सुरक्षा पुस्तकालय को बुला सकते हैं।

public Order GetMyOrder(int orderId) 
{ 
    Order o = GetOrderInternal(orderId); 
    BusinessSecurity.ValidateOrderForCurrentUser(o); 
} 

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

जब आप वस्तुओं का संग्रह लौटने और जिसके लिए वर्तमान उपयोगकर्ता उचित अधिकार नहीं हैं सभी वस्तुओं बाहर फ़िल्टर करना चाहते हैं, LINQ अभिव्यक्ति पेड़ काम में आ सकता है:

public Order[] GetAllOrders() 
{ 
    IQueryable orders = GetAllOrdersInternal(); 
    orders = BusinessSecurity.ApplySecurityOnOrders(orders); 
    return orders.ToArray(); 
} 

static class BusinessSecurity 
{ 
    public static IQueryable<Order> ApplySecurityOnOrders(
     IQueryable<Order> orders) 
    { 
     var user = Membership.GetCurrentUser(); 

     if (user.IsInRole("Administrator")) 
     { 
      return orders; 
     } 

     return 
      from order in orders 
      where order.Customer.User.Name == user.Name 
      select order; 
    } 
} 

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

अद्यतन (बाद के वर्षों):

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

तो PrincipalPermissionAttribute का उपयोग करने के बजाय, मैं decorators के साथ कोड लपेटकर सुरक्षा जैसे क्रॉस-कटिंग चिंताओं को लागू करता हूं। इससे मेरा आवेदन अधिक लचीला और परीक्षण करने में बहुत आसान बनाता है। मैंने पिछले कुछ वर्षों में इस तकनीक के बारे में कई लेख लिखे हैं (उदाहरण के लिए this one और this one)।

Answer 2

यदि आप एसओए का उपयोग कर रहे हैं, तो आप एक सुरक्षा सेवा बना सकते हैं, और प्रत्येक क्रिया (विधि) इसका संदर्भ भेज देगा (UserId, OrderId आदि)। सुरक्षा सेवा व्यापार सुरक्षा नियमों के बारे में जानता है।

योजना इस

UI -> Security -> BLL -> DAL 

Answer 3

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

नीचे दिया गया लेख पहलुओं को लागू करने और कोड को अलग रखने के 7 तरीके सूचीबद्ध करता है। एक दृष्टिकोण जो सरल है और आपके व्यवसाय तर्क इंटरफेस को नहीं बदलता है वह प्रॉक्सी का उपयोग करना है। यह आपके द्वारा वर्तमान में समान इंटरफ़ेस का खुलासा करता है, फिर भी एक वैकल्पिक कार्यान्वयन की अनुमति देता है, जो मौजूदा कार्यान्वयन को सजाने में सक्षम हो सकता है। हार्ड-कोडिंग या कस्टम विशेषताओं का उपयोग करके सुरक्षा आवश्यकताओं को इस इंटरफ़ेस में इंजेक्शन दिया जा सकता है। प्रॉक्सी आपकी व्यावसायिक परत पर विधि कॉल को रोकता है और उपयुक्त सुरक्षा जांच का आह्वान करता है। प्रॉक्सी के माध्यम से अवरोध को कार्यान्वित करना यहां विस्तार से वर्णित है - Decouple Components by Injecting Custom Services into your Object's Invocation Chain। अन्य एओपी दृष्टिकोण Understanding AOP in .NET में दिए गए हैं।

सलाह और सुरक्षा विशेषताओं का उपयोग करके कार्यान्वयन के साथ सुरक्षा को एक पहलू के रूप में देखते हुए forum post है। अंतिम परिणाम

public static class Roles 
{ 
    public const string ROLE_ADMIN = "Admin"; 
    public const string ROLE_CONTENT_MANAGER = "Content Manager"; 
} 

// business method  
[Security(Roles.ROLE_HR)] 
public List<Employee> GetAllEmployees(); 

आप अपने व्यापार विधि, तंग युग्मन पर सीधे विशेषता रख सकते हैं, या इन विशेषताओं के साथ एक सेवा प्रॉक्सी बनाने है, इसलिए सुरक्षा विवरण अलग रखा जाता है।