N層應用程序中的WCF和Silverlight 4.0：安全服務調用（無SSL，無信息安全，否x.509）

Question

我們的架構是一個簡單的N層模型，它由坐在IIS7中的ASP.Net應用程序（在DiscountASP中託管），這暴露了WCF服務的方法。這些方法使用EF4與數據庫交談。客戶端在Silverlight 4.0中。

三個要點：

• 認證和Authurazation是不是一個問題 - 到 服務調用匿名，我們不關心 呼叫者的身份。

• 傳入方法調用的數據在不敏感。

• 我們只是想確保任何人都無法撥打電話。

糾正我，如果在錯誤的：
信息安全是不是一種選擇，因爲它不支持Silverlight。
傳輸安全（HTTPS和X.509/SSL證書），也不能在Silverlight

所以我們採取的強制安全的一些級別的步驟來完成的：

• 一個密鑰硬編碼到XAP的dll中。

• 這個DLL是混亂的，所以它不能被重新設計。

• 密鑰作爲參數發送到所有服務方法 調用。

• 在每種方法開始時，檢查數據庫中原始座標的 密鑰。

• 從服務中刪除MetaDataExchange端點。

考慮這個最小的設置和它的許多缺陷，最大的缺陷可能是一個事實，即傳送不保證（HTTP），和祕密密鑰被暴露。所以問題是：

如果惡意用戶想要傷害我們的系統，他需要付出多少努力才能提取密鑰，找到暴露的方法並開始調用它們？

是否有其他的WCFcombiantion可以在每次調用時提供基本的憑證保護（無HTTPS或證書）？

Answer 1

好吧不，它變得更加清晰你的意思是在你的合同previous question合同的安全。安全包括several aspects。

• 認證和Authurazation是不是一個問題 - 到 服務電話是匿名的，我們不關心 呼叫者的身份。

• 我們只是想確保任何人都無法撥打電話。

這是一個矛盾。如果您希望確保所有您希望驗證的用戶都無法撥打電話。

• 在方法調用中傳輸的數據不靈敏。

考慮到這個最小的設置和它的許多缺陷，最大的缺陷可能是傳輸不安全（HTTP），並且密鑰被暴露。

另一個矛盾 - 你顯然想發送敏感數據。

信息安全不是Silverlight的一個選項 - 如果我們談論的消息加密和簽名是真實的，但你仍然可以在消息中傳遞用戶名和密碼，如果您使用HTTPS提供安全通道= TransportWithMessageCredential

找到一個密鑰需要多少努力？

• 如果你不使用HTTPS會發現每個人都與基本技能，並獲得網絡TRAFIC
• 如果你把在組件的鑰匙，它可能會需要更多的技巧，但仍是重點會在那裏（混淆難以對邏輯進行反向工程，但常數必須保持不變）。

如果你想確保你的傳輸並建立安全的解決方案，你必須使用HTTPS。通過HTTPS公開的服務可以被Silverlight使用。您還可以使用用戶名和密碼來識別您的客戶。客戶將負責保密用戶名和密碼，因爲如果他們不會，你會看到誰的帳戶傷害了你的應用程序。