2009-07-18 9 views
5

मैं सिल्वरलाइट वी 3 वेब ऐप पर काम कर रहा हूं और मैं अपने डेटा लाने के लिए उपयोग कर रहे डब्ल्यूसीएफ सेवा तक पहुंच सुरक्षित करना चाहता हूं। मेरे पास वर्तमान में डब्ल्यूसीएफ काम कर रहा है, लेकिन इसे किसी भी उपयोगकर्ता प्रमाण-पत्र की आवश्यकता नहीं है।डब्ल्यूसीएफ + उपयोगकर्ता क्रेडेंशियल्स

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

मैं अपनी सेवा प्रॉक्सी बनाने के बाद क्लाइंट साइड पर क्रेडेंशियल्स को अग्रिम रूप से निर्दिष्ट करने का एक तरीका है (मैं "सेवा संदर्भ जोड़ें" से स्वत: उत्पन्न प्रॉक्सी का उपयोग कर रहा हूं)।

इस के समाधान के लिए googling पर, मैं केवल अपने पहले विचार (उपयोगकर्ता नाम/पासवर्ड पैरामीटर का उपयोग कर) के समान समाधान ढूंढ सकता था। क्या कोई मुझे सही दिशा में इंगित कर सकता है?

धन्यवाद!

उत्तर

7

जहां इन उपयोगकर्ता नाम और पासवर्ड से आ रहे हैं? यदि आपकी वेबसाइट पहले से ही प्रपत्र प्रमाणीकरण लागू करती है तो आप सेटिंग प्रमाण-पत्र स्वयं को बाईपास कर सकते हैं और प्रपत्र प्रमाणीकरण कुकी का उपयोग कर सकते हैं।यदि आपके उपयोगकर्ता लॉग इन हैं तो कुकी वेब सेवा कॉल के साथ यात्रा करेगी। दूसरी तरफ इसे पढ़ने के लिए आपको कुछ बदलाव करने की जरूरत है। एक बार है कि प्रत्येक सेवा विधि के लिए तो किया जाता है

<system.serviceModel> 
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" /> 
</system.serviceModel> 

आप को समझने के लिए ASP.NET कुकी जोड़ना चाहते हैं:

सबसे पहले आप system.ServiceModel खंड में WCF के लिए ASP.NET संगतता मोड सक्षम करने की आवश्यकता [AspNetCompatibilityRequirements] प्रत्येक विधि के भीतर अब आपकी सेवा वर्ग

[ServiceContract] 
[AspNetCompatibilityRequirements(
    RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)] 
public class ExampleService 
{ 
} 

से जोड़कर देखते हैं आप उपयोगकर्ता की पहचान की खोज के लिए HttpContext.Current.User.Identity वस्तु पहुँच सकते हैं।

आप केवल कुछ तरीकों चाहते हैं प्रमाणीकृत उपयोगकर्ताओं के द्वारा कहा जा तो आप एक बोनस के रूप में एक PrincipalPermission इस प्रकार

[OperationContract] 
[PrincipalPermission(SecurityAction.Demand, Authenticated=true)] 
public string Echo() 

का उपयोग आप ASP.NET की भूमिका प्रदाता तो उन भी से भरी हुई होगी उपयोग कर रहे हैं कर सकते हैं और आप फिर उन्हें एक विशेष भूमिका के सदस्यों को सीमित करने के लिए तरीकों पर एक PrincipalPermission उपयोग कर सकते हैं:

[OperationContract] 
[PrincipalPermission(SecurityAction.Demand, Role="Administators")] 
public string NukeTheSiteFromOrbit() 

और यह रूप में अच्छी तरह स्पष्ट रूप से Silverlight2 में काम करता है।

+0

अच्छा लग रहा है; क्या आपको पता है कि कच्चे httpwebrequest का उपयोग करते हुए यह (या कुछ समान) उपयोग योग्य है या नहीं? मेरे पास एक कस्टम आरपीसी स्टैक है जो मैं उसी तरह से सुरक्षित करना चाहता हूं (यदि मैं एक गैर-मामूली उत्तर है तो मैं निश्चित रूप से एक नया क्वेस्टन के रूप में पूछ सकता हूं) –

+0

यह हाँ करना चाहिए; देखें http://www.silverlightshow.net/items/Cookies-in-Silverlight-Web-Requests.aspx – blowdart

+0

ता; मैं इसे देख लूंगा ;- –

0

आप किसी प्रकार की प्रमाणीकरण ऑब्जेक्ट में पास कर सकते हैं और इसे डब्ल्यूसीएफ के साथ संदेश स्तर पर एन्क्रिप्ट कर सकते हैं। सी # पहलुओं (http://www.postsharp.org/) का उपयोग अनावश्यक तर्क से बचने के लिए किया जा सकता है। इसे संभालने का यह एक बहुत ही साफ तरीका है।

1

अपना खुद का रोल न करें और स्पष्ट पैरामीटर जोड़ें - यह वास्तव में बहुत अधिक काम है!

डब्ल्यूसीएफ सुरक्षा सुविधाओं की जांच करें - उनमें से बहुत सारे उपलब्ध हैं! आप उदा। संदेश को सुरक्षित करें और संदेश के अंदर प्रमाण-पत्र शामिल करें - सभी बॉक्स के बाहर, आपकी तरफ से कोई अतिरिक्त कोडिंग आवश्यक नहीं है!

मिशेल लेरोक्स बस्टामेंटे द्वारा WCF सुरक्षा पर इस उत्कृष्ट लेख देखें: http://www.devx.com/codemag/Article/33342

आपके मामले में, मैं उपयोगकर्ता नाम पहचान के साथ संदेश सुरक्षा सुझाव देंगे - आप दोनों सिरों पर इस विन्यस्त करने की जरूरत:

सर्वर साइड:

<bindings> 
    <basicHttpBinding> 
    <binding name="SecuredBasicHttp" > 
     <security mode="Message"> 
     <message clientCredentialType="UserName"/> 
     </security> 
    </binding> 
    </basicHttpBinding> 
</bindings> 
<services> 
    <service name="YourService"> 
    <endpoint address="http://localhost:8000/MyService" 
       binding="basicHttpBinding" 
       bindingConfiguration="SecuredBasicHttp" 
       contract="IYourService" /> 
    </service> 
</services> 

और आप ग्राहक के पक्ष में एक ही सेटिंग्स लागू करने की आवश्यकता:

<bindings> 
    <basicHttpBinding> 
    <binding name="SecuredBasicHttp" > 
     <security mode="Message"> 
     <message clientCredentialType="UserName"/> 
     </security> 
    </binding> 
    </basicHttpBinding> 
</bindings> 
<client> 
    <endpoint address="http://localhost:8000/MyService" 
       binding="basicHttpBinding" 
       bindingConfiguration="SecuredBasicHttp" 
       contract="IYourService" /> 
</client> 

अब आप अपने सर्वर और ग्राहक सुरक्षा पर सहमत हैं - ग्राहक पर, आप तो इस तरह उपयोग करने के लिए उपयोगकर्ता नाम और पासवर्ड निर्दिष्ट करें:

YourServiceClient client = new YourServiceClient(); 

client.ClientCredentials.UserName.UserName = "your user name"; 
client.ClientCredentials.UserName.Password = "top$secret"; 

सर्वर साइड पर, आप की आवश्यकता होगी यह निर्धारित करने के लिए कि इन उपयोगकर्ता प्रमाण-पत्रों को कैसे सत्यापित किया जा रहा है - आम तौर पर या तो Windows डोमेन (सक्रिय निर्देशिका) के विरुद्ध, या ASP.NET सदस्यता प्रदाता मॉडल के विरुद्ध। किसी भी मामले में, यदि उपयोगकर्ता क्रेडेंशियल्स को उस स्टोर के विरुद्ध सत्यापित नहीं किया जा सकता है जिसे आप परिभाषित करते हैं, तो कॉल अस्वीकार कर दिया जाएगा।

उम्मीद है कि यह थोड़ा सा मदद करता है - सुरक्षा डब्ल्यूसीएफ में एक बड़ा विषय है और इसमें बहुत सारे विकल्प हैं - यह थोड़ा मुश्किल हो सकता है, लेकिन अंत में, आमतौर पर यह समझ में आता है! :-)

मार्क

+6

मुझे यकीन नहीं है कि आप किस परिदृश्य में ऐसा करने में सक्षम थे, लेकिन मेरे अनुभव में, डब्ल्यूसीएफ में इसकी अनुमति नहीं है। आप मूल एचटीपी बाइंडिंग में संदेश-मोड उपयोगकर्ता नाम-क्रेडेंशियल सुरक्षा का उपयोग नहीं कर सकते हैं, इसे ढांचे द्वारा अस्वीकृत किया गया है क्योंकि प्रमाण-पत्र सादे पाठ में पारित किए जाएंगे। आपको यह अवैधऑपरेशन अपवाद प्राप्त होगा: "BasicHttp बाइंडिंग के लिए आवश्यक है कि BasicHttpBinding.Security.Message.ClientCredentialType BasicHttpMessageCredentialType के बराबर हो। सुरक्षित संदेशों के लिए प्रमाणपत्र प्रमाण पत्र प्रकार। उपयोगकर्ता नाम क्रेडेंशियल्स के लिए परिवहन या TransportWithMessageCredential सुरक्षा का चयन करें।" – Grank

संबंधित मुद्दे