डब्ल्यूसीएफ सेवा प्राधिकरण पैटर्न

Question

मैं एक सुरक्षित डब्ल्यूसीएफ सेवा लागू कर रहा हूं। प्रमाणीकरण उपयोगकर्ता नाम/पासवर्ड या विंडोज प्रमाण पत्र का उपयोग कर किया जाता है। सेवा एक विंडोज सेवा प्रक्रिया में होस्ट किया गया है। अब, मैं प्रत्येक सर्विस ऑपरेशन के लिए प्राधिकरण को लागू करने का सबसे अच्छा तरीका खोजने का प्रयास कर रहा हूं।

public EntityInfo GetEntityInfo(string entityId); 

आपको बता दें कि, WCF में, वहाँ एक OperationContext वस्तु है जहाँ से आप कॉलर/ग्राहक द्वारा में पारित सुरक्षा क्रेडेंशियल को पुनः प्राप्त कर सकते हैं:

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

1. हम उदाहरण के जांच करने के लिए (मान्य है entityId:

   CheckAccessPermission(PermissionType.GetEntity, user, entityId) //user is pulled from the current OperationContext 
   

   अब, वहाँ सवालों के एक जोड़े हैं:

   हम इतनी तरह विधि की पहली पंक्ति में रख कहो शून्य/खाली मूल्य इत्यादि) प्राधिकरण जांच से पहले या प्राधिकरण जांच के अंदर? दूसरे शब्दों में, अगर प्राधिकरण जांच हर विधि में शामिल की जानी चाहिए, तो क्या यह एक अच्छा पैटर्न है? जो पहले होना चाहिए - तर्क सत्यापन या प्राधिकरण?

2. जब हम प्राधिकरण जांच इस तरह की जगह पर हैं, तो हम एक डब्ल्यूसीएफ सेवा का परीक्षण कैसे करते हैं, और हमारे पास इकाई परीक्षण में ऑपरेशन कॉन्टेक्स्ट नहीं है !? (मान लीजिए कि मैं किसी भी डब्ल्यूसीएफ सेटअप के बिना सीधे इस सेवा वर्ग कार्यान्वयन का परीक्षण करने की कोशिश कर रहा हूं)।

कोई विचार विचार लोग?

Answer 1

प्रश्न 1 के लिए, बिल्कुल पहले प्राधिकरण करें। कड़े सुरक्षा को बनाए रखने के लिए प्राधिकरण से पहले कोई कोड (आपके नियंत्रण में) निष्पादित होना चाहिए। उपरोक्त पौलुस का उदाहरण उत्कृष्ट है।

प्रश्न 2 के लिए, आप इसे अपने ठोस सेवा कार्यान्वयन को उप-वर्गीकृत करके संभाल सकते हैं। जैसा कि आप ऊपर उल्लेख करते हैं, एक वास्तविक "तर्कप्रणाली" विधि के साथ वास्तविक व्यापार तर्क कार्यान्वयन को एक अमूर्त वर्ग बनाएं। फिर 2 उप-वर्ग बनाएं, एक डब्ल्यूसीएफ उपयोग के लिए, और एक (एक गैर-तैनात डीएलएल में बहुत अलग) जो सत्य लौटाता है (या जो भी आप अपने यूनिट परीक्षण में करना चाहते हैं)।

उदाहरण (नोट, ये एक ही फ़ाइल या यहां तक ​​कि डीएलएल में भी नहीं होना चाहिए!):

public abstract class MyServiceImpl 
{ 
    public void MyMethod(string entityId) 
    { 
     CheckPermissions(entityId); 
     //move along... 
    } 
    protected abstract bool CheckPermissions(string entityId); 
} 

public class MyServiceUnitTest 
{ 
    private bool CheckPermissions(string entityId) 
    { 
     return true; 
    } 
} 

public class MyServiceMyAuth 
{ 
    private bool CheckPermissions(string entityId) 
    { 
     //do some custom authentication 
     return true; 
    } 
} 

फिर अपने WCF तैनाती वर्ग "MyServiceMyAuth" का उपयोग करता है, और आप अन्य के खिलाफ अपने इकाई परीक्षण करते हैं।

Answer 2

प्रश्न 1 के लिए, पहले प्राधिकरण करने के लिए सबसे अच्छा है। इस तरह, आप अनधिकृत उपयोगकर्ताओं को सत्यापन त्रुटि संदेशों को वापस रिसाव नहीं करते हैं।

बीटीडब्लू, घर से उगाए गए प्रमाणीकरण विधि (जो मुझे लगता है कि आपका चेकएपप्रिममिशन क्या है) का उपयोग करने के बजाय, आप एएसपी.NET भूमिका प्रदाताओं के लिए डब्ल्यूसीएफ के आउट-ऑफ-द-बॉक्स समर्थन को अपनाने में सक्षम हो सकते हैं। एक बार ऐसा करने के बाद, आप OperationContext.Current.ServiceSecurityContext.PrimaryIdentity.IsInRole() के माध्यम से प्रमाणीकरण करते हैं। प्राथमिक प्राथमिकता एक आईप्रिनिपल है।

Answer 3

बारे में प्रश्न # 2, मैं इस का उपयोग कर निर्भरता इंजेक्शन करते हैं और इस तरह से अपनी सेवा कार्यान्वयन कुछ सेट अप करना होगा:

class MyService : IMyService 
{ 
    public MyService() : this(new UserAuthorization()) { } 
    public MyService(IAuthorization auth) { _auth = auth; } 

    private IAuthorization _auth; 

    public EntityInfo GetEntityInfo(string entityId) 
    { 
      _auth.CheckAccessPermission(PermissionType.GetEntity, 
        user, entityId); 

      //Get the entity info 
    } 
} 

ध्यान दें कि IAuthorization एक अंतरफलक है कि आप को परिभाषित करेगा है।

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

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

मेरा पसंदीदा मॉकिंग फ्रेमवर्क RhinoMocks है जो मुफ़्त है और इसमें बहुत अच्छा धाराप्रवाह इंटरफेस है लेकिन वहां बहुत से अन्य लोग हैं। आप डि बारे में अधिक जानना चाहते हैं तो यहां कुछ अच्छी प्राइमरों और नेट चौखटे हैं:

• Martin Fowler on DI
• Jeremy Miller on DI
• Scott Hanselman's List of DI Containers
• मेरा व्यक्तिगत पसंदीदा डि कंटेनर: The Castle Project Windsor Container