如何安全地驗證WCF服務方法的調用程序集？

目前的情況如下：我們有一個生產.NET 3.5 WCF服務，通過整個組織的多個應用程序，超過的wsHttpBinding或NetTcpBinding的使用。用戶身份驗證正在使用Windows集成安全性在傳輸級別上完成。此服務有一個方法Foo(string parameter)，它只能由給定AD組的成員調用。字符串參數是強制性的。如何安全地驗證WCF服務方法的調用程序集？

一個新的客戶端應用程序已經開始發揮作用（.NET 3.5，C＃控制檯應用程序），從而消除了字符串參數的必要性。但是，只有來自這個特定應用程序的調用應該被允許省略字符串參數。客戶端應用程序的調用者的身份仍然應該由服務器知曉，因爲AD組限制仍然適用（排除客戶端上的模擬）。

我找到了一種方法來pass on the "evidence" of the calling (strong-named) assembly in the message headers，但這種方法顯然並不安全，因爲「證據」可以很容易被欺騙。另外，CAS（代碼訪問安全性）似乎是一種可能的解決方案，但我似乎無法弄清楚如何在這種特殊情況下使用CAS。

有沒有人對如何解決這一問題有何建議？

編輯：我發現another thread on this subject;顯然得出的結論是，以安全的方式實施是不可能的。

來源

2010-06-14 Tim

我還要提到的是客戶端應用程序的反編譯代碼不應該爲黑客提供模擬認證過程的信息。 – Tim 2010-06-17 08:42:35

聽起來對我來說就像您需要將安全性拉出到單獨的服務中一樣......使用更加聯邦的路由這種方式您可以實現使用公鑰和私鑰的握手形式來生成安全會話令牌兩種情況。

這樣你中央社仍然獲得兩個窗口A = uthentication和遊戲定製的解決方案，同時對安全方法保留您的屬性（我假設你用這種方法實現它。）

聽起來像一個公平的雖然有點工作 - 我必須從頭開始，並遇到一些跨域/委託問題。但我相信這個想法很好。

howver你會最終有一個很好的基礎堅實索賠secuirty模型

來源

2010-06-14 12:18:13

我必須說定製握手協議的想法超出了我的想法（不是很詳細，但確實:-)），但我放棄了它，因爲我認爲這會導致太多的工作和更多的問題。正如你的答案所證實的那樣。不過，如果這是唯一的方法;我想我只需要去做就可以了。你知道描述這種基於安全模型的索賠，WCF的服務範圍內的任何網頁？我仍然不清楚如何確保會話安全地認證我的客戶端應用程序。 – Tim 2010-06-15 14:08:37

睡在這個想法之後，我不禁想到單獨的服務將面臨與我最初的服務相同的問題：該服務也需要安全地驗證調用程序集以提供安全會話密鑰。這個假設是正確的還是我錯過了什麼？ – Tim 2010-06-17 08:49:12

我去度假了。那麼我的假設是你通過它的數據對組件沒有信任。通過異步加密，您可以旋轉鍵，使鍵在弱點中。通過旋轉服務器端的密鑰，即使客戶端不是100％安全的，攻擊者也沒有足夠的時間利用它。因此，如果您採用某種可信任的握手方式，您可以擁有一些自信的唯一方法。由於弱點將成爲客戶和初始溝通所使用的關鍵因素，因此這並不完美。但缺乏自信的是你的定義。 – 2010-07-01 12:06:08

你可以得到呼叫者地址：

RemoteEndpointMessageProperty clientAddress = 
    OperationContext.Current.IncomingMessageProperties[RemoteEndpointMessageProperty.Name] 
as RemoteEndpointMessageProperty; 
      string address = clientAddress.Address;

來源

2010-06-14 18:33:48 CkH

有趣的事實，但客戶端應用程序將需要從大量的機器運行。客戶地址在審覈中一定會有用處。 – Tim 2010-06-15 13:56:49

如何安全地驗證WCF服務方法的調用程序集？

回答

相關問題