एन-टियर ऐप में डब्ल्यूसीएफ और सिल्वरलाइट 4.0: सेवा

Question

पर कॉल प्रमाणित करें मेरे पास एक एन-टियर ऐप है जो निम्नानुसार बनाया गया है:
आईआईएस 7 में सर्वर की तरफ एक एएसपी.Net एप्लिकेशन बैठा है जो विधियों पर खुलासा करता है डब्ल्यूसीएफ सेवा। वे विधियां ईएफ 4 का उपयोग कर डीबी से बात करती हैं। सिल्वरलाइट 4.0 में लिखे गए ग्राहक डब्ल्यूसीएफ सेवा पर विधियों को बुला रहे हैं।

WCF सेवा इस विधि को उजागर करता है:

[OperationContract] 
void DeleteItem(int i_ItemId); 

मैं WCF सेवाओं seuring के लिए नया हूँ, लेकिन मुझे लगता है कि इन अगले टिप्पणियों सच (मुझे ठीक कर लें मैं गलत हूँ) कर रहे हैं:

1) अगर मैं इस विधि/सेवा को छोड़ देता हूं, कोई भी जो जानता है कि मेरी सेवा http://www.mysite.com/myservice.svc पर बैठी है, केवल विजुअलस्टूडियो खोल सकता है, "सेवा संदर्भ जोड़ें" खोलें और DeleteItem() पर कॉल करना प्रारंभ करें।

2) यदि मैक्स एंडपॉइंट को हटाकर उपर्युक्त हल करने का प्रयास करता हूं, तो सेवा के लिए कॉल अभी भी कुछ मैन्युअल कोडिंग का उपयोग करके किया जा सकता है।

तो उन दो समस्याओं को हल करने का प्रयास करना मैंने डब्ल्यूसीएफ में कुछ अंतर्निहित सुरक्षा सुविधाओं के बारे में सीखना शुरू किया। शीघ्रता से अवलोकन करने के बाद मैं समझ मैं निम्नलिखित बाध्यकारी विन्यास का उपयोग कर सकते हैं, जिससे कि एक उपयोगकर्ता नाम और पासवर्ड सेवा के लिए कॉल करने के लिए की जरूरत है:

<wsHttpBinding> 
    <binding name="RequestUserName" > 
     <security mode="Message"> 
     <message clientCredentialType="UserName"/> 
     </security> 
    </binding> 

इस समाधान को अपनाने के लिए कोशिश कर रहा है, पहली बात यह है कि मेरे दिमाग में आया था : जब कोई उपयोगकर्ता क्लाइंट में लॉग इन करता है, तो ग्राहक डब्ल्यूसीएफ कॉल के लिए क्रेडेंशियल के रूप में उपयोगकर्ता का नाम और पासवर्ड उपयोग करता है। सर्वर-साइड पर, उन प्रमाणपत्रों को डीबी के खिलाफ मान्य किया जाता है।

अब समस्या यह है कि, ये प्रमाण-पत्र (उपयोगकर्ता नाम और पासवर्ड) निश्चित रूप से उपयोगकर्ता को ज्ञात हैं, इसलिए वह केवल उन तरीकों से DeleteItem() को कॉल करने के लिए उनका उपयोग कर सकते हैं।

1) इसके बजाय प्रमाणिकता के रूप में उपयोगकर्ता नाम और पासवर्ड का उपयोग करते हुए, मैं ग्राहक में एक हार्ड-कोडेड कुंजी का उपयोग करेगा:

यहाँ से मैं दो समाधान के साथ आया था। एक्सएपी के अंदर डीएल के स्कैम्बलिंग से किसी को इस कुंजी को प्राप्त करने से रोका जा सकता है।

2) जब कोई उपयोगकर्ता क्लाइंट में लॉग इन करता है, तो सर्वर किसी प्रकार का एक अस्थायी टोकन (GUID या कुछ) भेजता है, जिसे क्लाइंट संचार के इस सत्र के दौरान अपने कॉल प्रमाणित करने के लिए उपयोग कर सकता है (मान लीजिए, उपयोगकर्ता तक ग्राहक बंद कर देता है)।

मेरा प्रश्न हैं:

क्या सुरक्षा स्तर है कि पहले समाधान प्रदान करता है और कितना मुश्किल आप यह दरार करने में काम करने की ज़रूरत है?

यदि पहला समाधान क्रैक करने के लिए बहुत छोटा है, तो क्या दूसरे समाधान में उल्लेख किए गए टोकन सिस्टम का प्रबंधन करने के लिए डब्ल्यूसीएफ में एक अंतर्निहित तरीका है?

अन्य समाधान जो दायरे को पैर कर सकते हैं उनका स्वागत है।

Answer 1

मुझे सुरक्षा स्तर के बारे में निश्चित नहीं है, जिसके बारे में आप पूछ रहे हैं, लेकिन मुझे XAP फ़ाइल में उपयोगकर्ता नाम और पासवर्ड को भरोसा नहीं करना चाहिए, obfuscated या नहीं।

मैं उस समाधान का वर्णन कर सकता हूं जिसे मैंने उत्पादन में लागू किया है।

असल में, मैं मानक फॉर्म प्रमाणीकरण के साथ एप्लिकेशन को सुरक्षित करता हूं, लेकिन मैं आमतौर पर एएसपी.NET के साथ रीडायरेक्ट का उपयोग नहीं करता, मैं प्रमाणीकरण वेब सेवा का उपयोग करता हूं जो एएसपी.नेट फॉर्म प्रमाणीकरण के साथ जहाजों का उपयोग करता है। इस तरह मेरा लॉगिन सिल्वरलाइट नियंत्रण के माध्यम से चला जाता है। मेरे ऐप में एक उपयोगकर्ता स्टोर है जो मैं प्रमाणीकरण सेवा को प्रमाणित करता हूं। जैसे आप रूपों के साथ सामान्य रूप से <deny users="?"> साथ <authorization> तत्व का उपयोग होता

protected void Application_Start(object sender, EventArgs e) 
{ 
    AuthenticationService.Authenticating += new EventHandler<AuthenticatingEventArgs>(AuthenticationService_Authenticating); 
} 

void AuthenticationService_Authenticating(object sender, AuthenticatingEventArgs e) 
{ 
    try 
    { 
     bool authenticated = //Call your user store here. 

     e.Authenticated = authenticated; 
    } 
    catch (Exception ex) 
    { 
     e.Authenticated = false; 
    } 
    e.AuthenticationIsComplete = true; 
} 

आप वेबसाइट के कुछ हिस्सों को सुरक्षित होगा:

प्रमाणीकरण सेवा करने के लिए हुक करने के लिए, मैं Global.asax में करते हैं। ब्राउज़र आपके लिए सभी कुकीज़ को संभालेगा। यदि आप सेवाओं को सुरक्षित करना चाहते हैं, तो सेवा/फ़ोल्डर के तहत आप इसे अधिकृत उपयोगकर्ताओं से इनकार नहीं करेंगे।

यह MSDN Post अधिक विस्तार से समाधान के बारे में बात करता है।