將令牌/ cookie傳遞給WCF服務的最佳策略？

我們正在用.net 4.0上的WCF構建一個Web服務。該服務將主要由ASP.net MVC前端使用，但也會被.net Windows應用程序使用。將令牌/ cookie傳遞給WCF服務的最佳策略？

提供的基本用戶名/密碼auth不會執行，因爲我們不想保存用戶憑據，所以我考慮使用RNGCryptoServiceProvider創建一個簡單的令牌（或者我應該稱之爲cookie？） .GetBytes（），然後使用它來驗證進一步的請求。

我已經研究過各種常用方法做保障與WCF，他們大多顯得過於複雜，尤其是當我們想要做的基本上是通過cookie來每一個方法調用。

什麼是從WCF客戶對我們的WCF服務通過這個cookie的最佳策略是什麼？首選方法將盡可能與WCF的安全架構緊密結合。

到目前爲止，我傾向於使用custom HTTP headers或custom authorization，但我不相信哪種方法更合適（如果有的話）。

請記住，對於ASP網站，一個新的通道將被爲每個請求創建的，而它將會在Windows應用程序中重複使用。

2011-11-22 ECC-Dan

這與C無關，我正在移除標記。 –

@JoachimPileborg我只會給C＃添加標籤，以表示我對收到的任何代碼示例的偏好。我應該在說明中指定這個嗎？ –

錯誤地將它標記爲C，而不是C＃。如果需要，您可以添加標籤。 –

IMO有兩種方法可以做wcf安全，運輸或Messsage。

您可以在應用程序中實現用戶名類型認證。所以客戶端必須填寫發送消息的用戶名和密碼。所以在客戶端結合會是什麼樣子

<security mode="TransportWithMessageCredential"> 
    <message clientCredentialType="UserName"/> 
</security>

在服務器端，你可以實現你自己的密碼驗證，如本example

這樣做將在服務器上驗證您的消息，您可以實現任何你想要的密碼驗證的邏輯。使用這個消息將使用SSL進行加密，並使用服務端實現的自己的邏輯進行身份驗證。

2011-11-22 17:04:06

這確實是我正在研究的內容，但我有點擔心由於爲每個傳入請求創建新通道，可能會導致性能下降。對此有何想法？ –

我不認爲你會因爲創建新頻道而面臨任何性能問題WCF在大多數情況下都能夠照顧到這一點 –

回答