安全性架構

本節會說明各種可用來修改或擴充 Windows Communication Foundation (WCF) 安全性元件功能的擴充點。若要瞭解這些擴充點，就必須先瞭解整體的 WCF 安全性架構。本主題會從 WCF 安全性架構之元件及其關係等觀點來介紹這種安全性架構，並在章節末說明擴充點如何搭配整體架構模型使用。

WCF 安全性元件的範圍

WCF 安全性牽涉到 WCF 架構中的多個元件。WCF 安全性的主要目標是提供完整性、機密性、驗證、授權，以及稽核由 WCF 架構建置在上方的應用程式。WCF 架構將這些功能分為下列部分：

• 「傳輸安全性」(Transfer Security)：負責提供訊息機密性、資料完整性及通訊方的驗證。
• 「授權」(Authorization)：負責提供做出授權決定的架構。
• 「稽核」(Auditing)：負責將安全性相關事件記錄到稽核記錄檔中。

此文件的安全性模式與範圍

使用下列其中一個「安全性模式」(Security Mode) 即可執行傳輸安全性：

• 傳輸這三種通訊安全性功能都是由用戶端與服務之間傳輸訊息使用的傳輸層所提供。
• 訊息傳輸安全性僅於 SOAP 訊息層提供，表示安全性會直接套用至 XML 層級的 SOAP 訊息。
• 傳輸與訊息認證在傳輸和訊息層上都提供傳輸安全性。傳輸層會提供通訊機密性、資料完整性及服務驗證。訊息則會提供用戶端驗證。

本文其餘內容將著重探討訊息安全性模式，不過其中有些資訊也適用於「傳輸與訊息認證」模式。具體地說，本文中適用於用戶端驗證的部分也適用於「傳輸與訊息認證」模式，因為「傳輸與訊息認證」模式使用訊息層執行用戶端驗證與「訊息」模式採用的方式相同。

授權與稽核元件的相關討論，也同樣適用於這三種全部的安全性模式。因此，所有與本文所介紹元件相關的資訊，都適用於所有支援的安全性模式。

訊息安全性模式概念

WS-Security 模型

訊息安全性模式的基礎是「WS-Security」(WS-Security) 規格。WS-Security 規格會定義允許安全性套用至 SOAP 訊息的架構。它會指定使用結合數位簽章與加密的安全性權杖之訊息安全性模式，以保護和驗證 SOAP 訊息。如需規格的詳細資訊，請參閱 Web 服務安全性 (WS-Security) (本頁面可能為英文)。

用語

「安全性權杖」(Security Token) 會判斷提示宣告，並可用來判斷提示在驗證密碼或金鑰與安全性識別之間的繫結。

「宣告」(Claim) 是指由實體 (Entity) 做出關於實體的宣告 (例如，名稱、身分識別、群組、金鑰、群組或權限)。做出宣告的實體稱為「宣告發行者」(Claim Issuer)，與已做出宣告有關的實體稱為「宣告主體」(Claim Subject)。

「宣告發行者」(Claim Issuer) 可以透過使用其金鑰來簽署或加密安全性權杖，以保證或加密在該安全性權杖中的宣告。這樣便可驗證在該安全性權杖中的宣告。

「訊息簽章」(Message Signature) 會用來確認訊息的來源與完整性。訊息產生者也可以使用訊息簽章來示範金鑰的知識 (通常指來自協力廠商的金鑰)，用以確認安全性權杖中的宣告，進而將其身分識別 (以及此安全性權杖所代表的任何其他的宣告) 繫結至訊息產生者所建立的訊息。

安全性權杖

WS-Security 定義數種安全性權杖類型，另外也提供可擴充模型，允許獨立定義其他安全性權杖的類型。每一種權杖類型定義都會包含該權杖的 XML 序列化 (Serialization) 形式。這樣便會允許將該權杖表示方式直接新增到訊息中。

下列是一些定義在 WS-Security 中的安全性權杖類型：

• 使用者名稱權杖。
• X.509 憑證權杖。
• Kerberos 權杖。
• SAML 權杖。

使用權扙有四種的已定義的方法，而附加到特定訊息的權扙便是這類方法的其中一種：

• SignedSupporting
• SignedEndorsing
• SignedEncrypted
• EncryptedEndorsing

在 .NET Framework 3.0 中，用戶端訊息只會包含任何指定類型的一個權杖，但是可以包含不同類型的多個權扙。

在 .NET Framework 3.5 中，用戶端訊息只會包含任何指定類型的多個權杖，以及不同類型的多個權扙。

這項功能適用於一些案例，包括下列：

• 累加宣告傳送：服務上的所有作業可能都需要有一組宣告，但有些作業可能會需要額外的宣告。用戶端不會在每個作業上使用不同的發行權杖，而會以一組初始宣告取得發行的權杖，並使用呼叫作業所需的剩餘宣告使用其他發行權杖。
• 多重要素驗證：當用戶端必須先收集來自多個發行者所發行的權杖，或以不同宣告集合所發行的權杖，才能允許執行作業時。WCF 將發行的權杖視為權杖的類型，所以本案例需要在訊息中能夠有兩個支援的發行權杖。

請注意，設定服務時，服務絕對不可以只包含一個支援權杖。

如需詳細資訊，請參閱 HOW TO：使用相同類型的多個安全性權杖。

WS-Security 實作

由於 WS-Security 奠定了訊息安全性的基礎，所以 WS-Security 的 WCF 實作 (Implementation) 就是整個訊息安全性模式的柱石。若要擴充訊息安全性模式功能，我們就必須瞭解 WS-Security 實作的運作方式。

WCF 中的 WS-Security 實作會處理下列作業：

• 相互序列化安全性權杖與 SOAP 訊息。
• 驗證安全性權杖。
• 驗證和應用訊息簽章。
• 加密和解密 SOAP 訊息。

您可以透過 WCF 擴充點來自訂前面兩項作業。您可以變更成序列化現有的安全性權杖，或是改變 WCF 安全性驗證這些權杖的方式。您也可以將全新的安全性權杖類型引進到 WCF 安全性中，其中包括序列化及驗證功能。

本節中的下列主題還會示範如何使用 WS-Security 實作擴充點來自訂安全性權杖功能。

授權

安全性權杖會從傳入的訊息還原序列化並完成驗證。驗證程序會產生一組授權原則物件。每個物件都代表安全性權杖資料的某一部分。這類資料會在授權階段期間加以應用。

「授權原則」(Authorization Policy) 會建立指定之安全性權杖所代表的宣告集。然後，這個宣告集便會因應授權決策而提供給 ServiceAuthorizationManager 與 AuthorizationContext 屬性內的邏輯。

身分識別

除了宣告以外，WCF 也會建立 IIdentity 介面的實作，以表示針對現有基礎結構 (由 .NET Framework 安全性模式建立) 的呼叫者。這個 IIdentity 執行個體 (Instance) 會表示呼叫者的 Windows 身分識別 (若此安全性權杖是對應至 Windows 帳戶)，或是包含該呼叫者名稱的主要身分識別。這些身分識別也可以使用 ServiceSecurityContext 來加以存取 (如需詳細資訊，請參閱 HOW TO：檢查安全性內容)。您可以使用下列其中一種方法來自訂在 WCF 中建立身分識別的方式：

• 實作 SecurityTokenAuthenticator 類別的自訂延伸。
• 透過擴充 MembershipProvider 類別，或是建立自訂 IAuthorizationPolicy 實作並將其插入 ServiceAuthorizationManager，以便與 ASP.NET 整合。
• 建立自訂的 IAuthorizationPolicy。

只有在使用者名稱/密碼驗證是用來驗證呼叫者時，自訂成員資格提供者才能運作。MembershipProvider 會驗證 (Validate) 使用者名稱/密碼組。如果是有效的組合，WCF 便會在進行 MembershipProvider 驗證之後建立表示已通過驗證之呼叫者的主要身分識別。

為了簡化與現有 .NET Framework 安全性基礎結構整合的程序，WCF 預設會將 CurrentPrincipal 屬性設定為表示該呼叫者的 IPrincipal 執行個體。IPrincipal 執行個體是依據產生的 IIdentity 之中所含資訊而建立。

藉著與 ASP.NET RoleProvider 進行整合，IIdentity 即可進一步增強。RoleProvider 會新增呼叫者所屬的角色集。驗證邏輯則會利用這項資訊來做出存取決策。

如需 身分識別的詳細資訊，請參閱服務身分識別和驗證。

傳送安全訊息

下圖顯示如何在使用訊息安全性模式時保護用戶端上的訊息。此圖會顯示其中牽涉到哪些元件，以及這些元件之間的關聯性：

1. 應用程式程式碼會執行並產生訊息。
2. 在「權杖提供」(Token Provisioning) 階段中會附加用戶端認證 (例如 X.509 憑證)。在聯合安全性案例中，則會連絡權杖發行者以提供認證。
3. 這些認證會用來建立安全性權杖。
4. 在「權杖驗證」(Token Authentication) 階段中會對權杖進行確認。
5. 最後，則會序列化並傳送安全性權杖。

接收安全訊息

下圖會說明從線上擷取安全訊息，並在接收端確認該訊息時所進行的程序：

1. 安全性權杖會在權杖驗證階段中進行還原序列化和處理。如果需要的話，可在此時使用 ASP.NET 成員資格提供者來提供使用者名稱及密碼。
2. 在驗證過後，授權原則便完成擷取。
3. 在「授權原則評估」(Authorization Policies Evaluation) 階段中會評估授權原則，並可將宣告新增到「評估內容」(Evaluation Context) 中。此時也會用到外部授權原則。這個步驟以及下列步驟是由 ServiceAuthorizationManager 的方法完成的。
4. 在「服務授權」(Service Authorization) 階段中會根據授權原則所新增的宣告來指定正確的授權。這個步驟是由 ServiceAuthorizationManager 的方法完成。
5. 在授權發生之後，如果呼叫者有允許模擬，而且服務方法也需要模擬，或是在服務授權行為上有設定 ImpersonateCallerForAllOperations 屬性，便會發生呼叫者模擬。如需詳細資訊，請參閱 使用 WCF 的委派和模擬。
6. WCF 會在此時產生使用這些認證的 PrincipalPermission。如果有需要的話，可在此時使用 ASP.NET 角色提供者。
7. 應用程式程式碼便會執行。

安全性擴充點的概觀

下圖顯示由 WCF 安全性元件提供的擴充點。此圖會根據擴充點在訊息處理期間的到達時間來分成四個不同分類。這些分類會對應至前面二節所介紹的訊息安全性處理階段。此圖也會顯示可以與 WCF 安全性整合的現有基礎結構技術。

請參閱

參考

PrincipalPermission
ServiceAuthorizationManager
ServiceSecurityContext

概念

Windows Communication Foundation 架構
使用 WCF 的委派和模擬

其他資源

自訂認證與認證驗證