為使用 ASP.NET 建立的 XML Web Service 設定安全性

決定 Web 服務最適用的安全性實作時,首先要審視兩項主要安全性準則:驗證和授權。驗證 (Authentication) 是根據認證 (例如,使用者名稱和密碼),向授權單位確認身分識別有效性的程序。當身分識別通過驗證後,授權程序將判斷身分識別是否獲得授權可以存取資源。

使用 ASP.NET 所建立的 Web 服務可以從 ASP.NET 或自訂 SOAP 安全性提供的驗證和授權選項中選擇安全性選項。ASP.NET 會搭配網際網路資訊服務 (IIS) 運作,以提供數種驗證和授權選項。您也可以建立自訂驗證選項,例如,讓您選擇使用 SOAP 標頭。此外,ASP.NET 還提供所謂「模擬」的能力,讓您可以使用用戶端認證來執行要求。如需使用模擬的詳細資訊,請參閱 ASP.NET 模擬

本主題摘要說明使用 ASP.NET 建置之 Web 服務可用的驗證和授權選項。如需 ASP.NET Web 應用程式可用安全性選項的詳細資訊,請參閱保護 ASP.NET Web 應用程式建置安全的 ASP.NET 應用程式:驗證、授權及安全通訊 (本頁面可能為英文)。

如需從 ASP.NET 應用程式存取遠端資源的詳細資訊,請參閱建置安全的 ASP.NET 應用程式第 3 章中的<模擬/委派模型>和<信任子系統模型>主題 (本頁面可能為英文)。

XML Web Service 的驗證選項

使用 ASP.NET 建立的 Web 服務有許多用於驗證用戶端的選項,所以「哪一個選項最適合特定的 Web 服務」成了一個大問題。在選擇適當的安全性選項時,需要開發人員在其間做抉擇的一件事就是安全等級與效能的取捨。對某些 Web 服務來說,使用加密在網路上傳送用戶端認證相當重要,因此加密用戶端認證的演算法是不可或缺的一環。例如,對撰寫處理信用卡之 Web 服務的開發人員而言,比起加密信用卡資料時的額外負荷,他可能更擔心用戶端認證遭竊。

下表摘要說明使用 ASP.NET 建置之 Web 服務可用的驗證選項。前面加上 Windows 的選項是使用 ASP.NET 建立之 Web 服務可用的 Microsoft Windows 驗證選項部分。

驗證選項摘要

驗證選項 描述

Windows - 基本驗證

用於用戶端的非安全識別,因為它會在 Base 64 編碼字串中,以純文字傳送使用者名稱和密碼。在這種驗證類型中,密碼和使用者名稱雖然經過編碼,但是沒有加密。居心不良的使用者只要具備網路監視工具,就可以攔截使用者名稱和密碼。

Windows - Basic over SSL 驗證

用於網際網路情況下的用戶端安全識別。在網路上傳送時,使用者名稱和密碼是使用 Secure Sockets Layer (SSL) 加密,而不是使用純文字。這在網際網路情況下相當容易設定和使用。不過,使用 SSL 會降低效能。

Windows - 摘要式驗證

用於網際網路情況下的用戶端安全識別。它使用雜湊加密的方式傳送用戶端認證,所以不會以純文字傳送密碼。此外,您還可以透過 Proxy 伺服器使用摘要式驗證。不過,這種驗證並未在其他平台上受到廣泛支援。

Windows - 整合式 Windows 驗證

使用 NTLM 或 Kerberos。它會使用與使用者的 Microsoft Internet Explorer Web 瀏覽器之間進行的密碼編譯交換。

Windows - 用戶端憑證驗證

用於網際網路和內部網路情況下的用戶端安全識別。它會要求每個用戶端必須從相互信任的憑證授權單位取得憑證。您可以選擇性地將憑證對應到 IIS 用來授權存取 Web 服務的使用者帳戶。

表單驗證

Web 服務不支援此驗證。在這種系統下,會使用 HTTP 用戶端重新導向,將未經驗證的要求重新導向至 HTML 表單 。Web 服務的用戶端多半不想要使用 UI 來提供認證;如果您想要使用表單驗證,就必須解決這個問題。

SOAP 標頭 – 自訂驗證

在安全和非安全的網際網路情況下都適用。它會在 SOAP 訊息的 SOAP 標頭中傳遞使用者認證。無論裝載 Web 服務的平台為何,Web 伺服器都會提供自訂驗證實作。

對於上列任何選項,除了使用 SOAP 標頭之外,都可以搭配使用組態檔 和 IIS 來指定其安全性設定。因為自訂 SOAP 標頭選項同時涉及驗證和授權,所以會在「授權」一節之後接著說明這個解決方案。

Windows 驗證

IIS 和 ASP.NET 都會使用 Windows 內建的安全性,來提供驗證 Web 應用程式 (包括 Web 服務) 的支援。Windows 提供了三個驗證選項:基本、摘要式和整合式 Windows 驗證。此外,每個選項都可以和 SSL 一起使用。由於除了基本驗證之外,所有的 Windows 驗證選項都會以某種形式來加密資料,所以 SSL 提供的額外加密層級通常只會和基本或用戶端憑證搭配使用。

無論使用哪一個 Windows 驗證選項,設定 Web 服務與設定 Web 服務用戶端的程序都相同。如需詳細資訊,請參閱 HOW TO:設定 XML Web Service 進行 Windows 驗證。因為會在組態檔和 IIS 中設定驗證選項,所以使用 Windows 驗證時不需要在 Web 服務中新增程式碼。但是您必須將用來傳遞用戶端認證給 Web 服務的程式碼新增至 Web 服務用戶端。

如果選擇 SSL 做為 Web 服務使用的驗證機制的一部分,則必須使用 IIS 來為裝載 Web 服務的 Web 應用程式或 Web 服務本身設定 SSL。服務描述以及後來從服務描述產生的 Proxy 類別將會反映出 Web 服務是使用 SSL (如果使用 SSL 存取服務描述和服務說明網頁的話)。在服務描述中,Web 服務的 URL 前面會加上 https。如需設定 SSL 的詳細資訊,請參閱 IIS 文件。

用戶端憑證驗證

當需要用戶端傳送電子文件、呼叫用戶端憑證,並使用 Web 伺服器的 SSL 連線識別用戶端時,用戶端憑證將有助於提供驗證的安全機制。SSL 連線會在透過網路傳送用戶端憑證內含的用戶端認證時予以加密。用戶端和 Web 伺服器之間的通訊會透過結合用戶端傳送的加密金鑰與 Web 伺服器提供的金鑰來進行加密。一旦建立通訊後,就只有用戶端和伺服器電腦可以使用該 SSL 連線彼此相互通訊。

用戶端憑證可以從憑證授權單位取得,而這個授權單位可能是 Web 伺服器本身或用戶端和伺服器之間信任的媒介。一旦取得憑證,而且 Web 伺服器已設定為可以接受用戶端憑證的話,用戶端就可以在呼叫 Web 服務時,透過 SSL 連線將用戶端憑證傳送至 Web 伺服器。如需用戶端憑證的詳細資訊,請參閱 IIS 文件。如需設定 Web 服務之用戶端憑證驗證的詳細資訊,請參閱 HOW TO:設定 XML Web Service 進行 Windows 驗證

XML Web Service 的授權選項

授權的目的在判斷是否應該授與某個身分識別對指定資源要求的存取類型。有兩種基本方式可以授與特定資源的存取權:檔案授權和 URL 授權。只要使用 Windows 驗證,就可以使用檔案授權,因為權限是在 IIS 中針對每個檔案設定的。URL 授權可以用於 ASP.NET 支援的任何內建驗證機制。使用 URL 授權時,組態是透過組態檔完成,您可以在這個檔案中選擇性地允許或拒絕使用者存取任何與 ASP.NET 有關聯的檔案,包括 .asmx 檔案。

如需針對個別檔案設定授權的詳細資訊,請參閱 IIS 文件。

如需使用組態檔設定授權的詳細資訊,請參閱 ASP.NET 授權

使用 SOAP 標頭自訂驗證

Windows 驗證機制 (包括用戶端憑證) 需要依賴 HTTP 傳輸,而 SOAP 則與傳輸無關。使用 ASP.NET 建置的 Web 服務會使用 SOAP over HTTP 以及傳回非 SOAP XML 文件的 HTTP-POST 和 HTTP-GET 實作。因此,建立自訂驗證機制的其中一個理由是要讓驗證擺脫與傳輸的聯結。您可以在 SOAP 標頭中傳遞驗證認證,來達成這個目的。

傳遞 Out-of-Band 資訊或與 Web 服務語意 (Semantics) 無關聯的資訊時,SOAP 標頭是個好方法。與 SOAP 訊息的 Body 項目 (其中包含用於 Web 服務作業,而由 Web 服務方法所處理的 in 和 out 參數) 不同,Header 項目是一個選擇項 (Optional),因此可以由基礎結構進行處理。也就是,專為提供自訂驗證機制而開發的基礎結構會負責處理這個項目。

如需某個使用 SOAP 標頭進行驗證的方法說明,請參閱 HOW TO:使用 SOAP 標頭執行自訂驗證

為了使用 SOAP 標頭進行驗證,Web 服務用戶端會將所需的 SOAP 標頭新增至 SOAP 要求並填入用戶端認證,以傳送認證給 Web 服務。若要使用 SOAP 標頭驗證,Web 服務必須做兩件事:指定它所接受的 SOAP 標頭必須含有驗證認證,以及將用戶端存取權授與 Web 服務。

請參閱

工作

HOW TO:設定 XML Web Service 進行 Windows 驗證
HOW TO:使用 SOAP 標頭執行自訂驗證

參考

NetworkCredential
CredentialCache
X509Certificate

其他資源

保護 ASP.NET Web 應用程式
使用 ASP.NET 建置 XML Web Service

Footer image

Copyright © 2007 by Microsoft Corporation. All rights reserved.