WCF BasicHttpBinding 安全解析（4）windows驗證（IIS宿主）

  現在我們讨論TransportCredentialOnly安全模式下的安全配置，首先在配置檔案中添加如代碼清單11-84所示的配置節，配置windows驗證。Windows憑據認證是基于Windows組賬戶或者域賬戶進行認證的方式。在這種認證方式下，用戶端程序運作的Window帳号對應的Windows憑證被自動作為調用服務的用戶端憑證，是以無需顯示指定具體的Windiws憑證。如果需要另一個Windows帳号的名義調用服務，用戶端就需要通知指定Windows帳号和密碼的方式顯式地進行用戶端Windows憑證的設定。Windows憑證在WCF通過類型WindowsClientCredential表示。真正的憑證最終儲存在類型為NetworkCredential的ClientCredential屬性中。通過該屬性，你可以指定Windows憑證的域名、使用者名和密碼。

注：

TransportCredentialOnly安全模式是明文傳輸，這裡是為了檢視通信細節才采用這種方式，實際場景不推薦使用。

代碼清單11-84 配置windows驗證

看清單11-84，通過<ecurity mode=" TransportCredentialOnly ">”設定安全模式為TransportCredentialOnly，然後通過設定<transport clientCredentialType="Windows">設定用戶端憑據類型為Windows。此外我們需要設定站點的認證模式為Windows，設定方式如代碼清單11-85。

代碼清單11-85 設定站點的認證模式為Windows

服務端更改完畢之後，還有確定IIS開啟了Windows認證。最後我們更新用戶端的服務引用，右鍵服務引用，然後單擊“更新服務引用”，我們會看到如圖11-36所示的彈出框。

<a href="http://images.cnblogs.com/cnblogs_com/xuanhun/201106/201106291118479908.gif"></a>

圖11-36 更新服用引用需要驗證憑據

輸入驗證資訊之後，用戶端的安全配置更新為代碼清單11-86所示的内容。

代碼清單11-86 windows認證時用戶端安全配置

我們傳遞一個錯誤的使用者賬戶資訊，啟動測試站點，會得到如圖11-37所示的錯誤資訊。

<a href="http://images.cnblogs.com/cnblogs_com/xuanhun/201106/201106291118501841.gif"></a>

圖11-37 windows身份驗證未通過

圖11-37所示的錯誤資訊是因為用戶端未提供正确的身份驗證資訊導緻的。實際上用戶端和服務端經過了三次協商，最後一次的服務端響應資訊如代碼清單11-87。

代碼清單11-87 驗證失敗的服務端響應資訊頭

傳回401權限驗證失敗的資訊，驗證标頭為Negotiate和NTLM。

Negotiate 身份驗證協定包是 Windows 中的一個安全支援提供程式 (SSP)，它提供身份驗證和加密。它的作用是基于用戶端計算機和伺服器上支援的協定協商要用于身份驗證請求的身份驗證協定。在 Windows 7 和 Windows Server 2008 R2 之前的 Windows 版本中，Negotiate 包支援 NTLM 和 Kerberos。對于 Windows 7 和 Windows Server 2008 R2，已經對 Negotiate 包進行了更新，以支援更多 SSP。

出現上面的錯誤資訊實際上是因為我的IIS的Windows驗證預設提供成為Negotiate和NTLM，當然我們還可以添加Kerberos驗證方式。

那個如何在用戶端附加Windows身份驗證資訊呢？代碼清單11-88是修改後的用戶端代碼。

代碼清單11-88 設定windows賬戶資訊

在代碼清單11-88中，我們通過設定client.ClientCredentials.Windows.ClientCredential的Domain屬性來設定域資訊，通過UserName屬性設定使用者名，通過Password屬性設定密碼。

說明：

正常情況下，用戶端和伺服器在同一個域環境中，是不需要傳遞使用者名和密碼的。

運作結果如圖11-38。

<a href="http://images.cnblogs.com/cnblogs_com/xuanhun/201106/201106291118546664.gif"></a>

圖11-38 Windows驗證

本文轉自懸魂部落格園部落格，原文連結：http://www.cnblogs.com/xuanhun/archive/2011/06/29/2093119.html，如需轉載請自行聯系原作者