WCF的安全體係主要包括三個方麵：傳輸安全（Transfer Security）、授權或者訪問控製（Authorization OR Access Control）以及審核（Auditing）。而傳輸安全又包括兩個方麵：認證（Authentication）和消息保護（Message Protection）。認證幫助客戶端或者服務確認對方的真實身份，而消息保護則通過簽名和加密實現消息的一致性和機密性。WCF采用兩種不同的機製來解決這三個涉及到傳輸安全的問題，我們一般將它們稱為不同的安全模式，即Transport安全模式和Message安全模式。

目錄
一、Transport安全模式
             1.1 TLS、SSL和HTTPS
             1.2 Transport安全模型的優缺點
二、Message安全模式
          2.1 WS-Security
          2.2 WS-Trust
          2.3 WS-SecurreConversation
          2.4 WS-SecurityPolicy
          2.5 Message安全模式的優缺點
三、Mixed安全模式

注：由於英文中的Transfer Security和Transport Security都可以翻譯成傳輸安全，以示區別，我用中文的“傳輸安全”表示涉及到認證、消息一致性和機密性的Transfer Security，而采用“Transport安全（模式）”表示基於某種網絡協議的傳輸層安全（模式），與“Transport安全（模式）”相對的是“Message安全（模式）”。

顧名思義，Transport安全模式就是利用基於傳輸層協議的安全機製解決傳輸安全涉及的三個問題，即認證、消息一致性和進行性。而TLS/SSL是實現Transport安全最常用（並非唯一）的方式。

TLS、SSL和HTTPS

任何一本介紹WCF的書，在介紹Transport安全模式的時候，必然會提到SSL或者HTTPS，有時還會提到TLS。有一些人不太明白這三者到底有什麼區別，尤其是不能很好的區分TLS和SSL的差別。在這裏，我們就先來簡單介紹一下這三個相關的概念。

SSL（Secure Sockets Layer）最初是由Netscape公司開發的一種安全協議，應用於Netscape瀏覽器以解決與Web服務器之間的安全傳輸問題。SSL先後經曆了三個主要的版本，即1.0、2.0和3.0。之後SSL被IETF （Internet Engineering Task Force）接管，正是根名為TLS（Transport Layer Security）。可以這麼說，SSL是TLS的前身，TLS 1.0相當於SSL 3.1。

TLS/SSL本身是和具體的網絡傳輸協議無關的，既可以用於HTTP，也可以用於TCP。而HTTPS（Hypertext Transfer Protocol Secure）則是將HTTP和TLS/SSL兩者結合起來。在一般情況下，HTTPS通常采用443端口進行通信。對於WCF來說，所以基於HTTP協議的綁定的Transport安全都是通過HTTPS來實現的。而NetTcpBinding和NetNamedPipeBinding也提供了對TLS/SSL的支持，一般我們將TLS/SSL在TCP上的應用稱為SSL Over TCP。

TLS/SSL幫助我們解決兩個問題：客戶端對服務端的驗證，以及通過對傳輸層傳輸的數據段（Segment）進行加密確保消息的機密性。出於性能的考慮，這裏采用的是對稱加密而不是非對稱加密。接下來，我從消息交換的角度來說明上述的兩個問題是如何通過TLS/SSL解決的。

我們以訪問一個HTTPS站點為例。當客戶端和這個HTTPS站點所在的Web服務器進行正式的訪問請求之前，在它們之間必須建立了安全的HTTP連接。而這樣一個安全的連接的創建通過客戶端和Web站點之間的多次握手或者協商（Negotiation）來完成。如下圖示，整個協商過程主要包括三個步驟。

步驟一：客戶端向HTTPS站點發送協商請求，該請求中包括客戶端所能夠支持的加密算法列表；

步驟二：HTTPS站點從加密算法列表中選擇自己支持的並且安全級別最高的算法（有時候站點也可能綜合考慮性能和安全兩者之間的平衡，從中選擇一個“最佳”的加密算法），連同綁定到該站點的數字證書（所有HTTPS站點在部署的時候都會綁定一個X.509證書）一並發送給客戶端；

步驟三：客戶端接收到服務端發回的數字證書之後，通過驗證證書進而確定服務身份。在驗證成功的情況下，客戶端會生成一個隨機隨機數，作為會話密鑰（Session Key），緩存在客戶端。客戶端隨後並采用服務端發回的加密算法，利用從證書中提取的公鑰進行加密。加密後的會話密鑰被發送給服務端，服務端使用自己的私鑰采用相對應的算法進行機密得到該會話密鑰。至此，客戶端和服務端具有一個隻有它們彼此知曉的會話密鑰，所有的請求和回複消息均通過該會化密鑰進行加密和解密。

有人可能會說，客戶端為何不直接用從數字證書提取的公鑰對所有的請求消息進行加密，服務端采用私鑰進行解密。之所以選擇對稱加密而不是非對稱加密，主要有兩方麵的原因：

• 對稱加密/解密比非對稱加密/解密需要更少的計算，所以具有更好的性能；
• 上述的加密方式隻能確保客戶端向服務端請求消息的機密性，而不能保證服務端向客戶端回複消息的機密性。

Transport安全模型的優缺點

較之我們後續介紹的Message安全模式，Transport安全模式具有一個最到的優點，那就是高性能。雖然TLS/SSL在正式進行消息交換之前需要通過協商建立一個安全的連接，但是這個協商過程完全通過傳輸層協議來完成。而且這種安全模式還可以充分利用網絡適配器的硬件加速，這樣就可以介紹CPU時間，進而提供性能。但是，受限於傳輸層安全協議的特點，Transport安全模式也具有一些不可避免的局限性：

• Transport安全模式依賴於具體的傳輸協議；
• 它隻能提供基於點對點（Point-to-Point）的安全傳輸保障，即客戶端之間連接服務的場景。如果在客戶端的服務端之間的網絡需要一些用於消息路由的中間結點，Transport安全模式則沒有了用武之地。
• 在Transport安全模式下，意味著我們不得不在傳輸層而不能在應用層解決對客戶端的認證，這就決定了可供選擇的認證方式不如Message模式多。

也正是由於上述的這些局限（主要還是隻能提供點對點的安全傳輸保障），決定了Intranet是Transport安全模式主要的應用環境。為了克服這些局限，我們需要一種與傳輸協議無關的、能夠提供端到端（End-to-End）安全傳輸保障的、具有多種認證解決方案的安全模式，那就是Message安全模式。

Transport安全模式將安全傳輸策略應用到傳輸層的數據段，進而間接地實現基於消息的安全傳輸。而Message模式則直接將安全策略的目標對象對準消息本身，通過對消息進行簽名、加密實現消息安全傳輸。所以Message安全模式不會因底層是HTTP或者TCP傳輸協議而采用不同的安全機製，並且能夠提供從消息最初發送端到最終接收端之間的安全傳輸，即端到端（End-To-End）安全傳輸。Message模式下的安全協議是一種應用層協議，我們可以在應用層上實現對客戶端的驗證，因而具有更多的認證解決方案的選擇。

此外， WCF的Message安全模式並不是微軟在Windows平台下的閉門造車，而是遵循一係列開放的標準或者規範，那就是圍繞著WS-Security的四個WS-*規範，即WS-Trust、WS-Secure Conversation和WS-Security Policy。這就意味著WCF的Message安全具有很好的互操作性或平台無關性。

WS-Security

WS-Security由是由結構化信息標準促進組織（OASIS：Organization for the Advancement of Structured Information Standards）製定。對於本書的讀者來說，我相信你應該不會對OASIS這個組織感到陌生了吧。不僅僅是WS-Security，包括我們接下來要介紹的WS-Trust、WS-Secure Conversation和WS-Security Policy，它們的製定者也是這個標準組織。

WS-Security，有時候又被簡稱為WSS，製定了一整套標準的基於SOAP（包括SOAP 1.1和SOAP 1.2）的擴展以幫助創建一個安全的Web服務。到目前為止，OASIS推出了兩個版本，第一個正式的版本於2004年3月發布，即WS-Security 1.0，有時候被稱為WS-Security 2004。2006年2月，OASIS發布了WS-Security 1.1。

定義在WS-Security中的SOAP的安全機製可以廣泛地應用於現有的多種安全模式下，比如PKI、Kerberos和SSL等。WS-Security支持多種安全令牌（Security Token）格式（比如用戶名/密碼、SAML、X509證書和Kerberos票據等）、多種簽名格式和加密技術。針對具體的安全令牌，WS-Security通過對應的Profile文檔進行單獨定義。

WS-Security提供了關於SOAP安全交換的三個主要機製：如何將安全令牌作為消息的一部分進行傳輸，如何檢測接收到的消息是否和原始發送的一致，以及如何確保消息的真實內容僅對真正的接收者可見。安全令牌的傳輸主要解決身份認證的問題，所以這三個方麵就是傳輸安全麵對的三個問題：身份認證、消息一致性和消息機密性。WS-Security提供了一個抽象的消息安全模型。在這個安全模型中，通過安全令牌，結合數字簽名和加密技術實現對消息交換實體的認證和對消息本身的保護。

WS-Trust

WS-Trust通過定義了一係列SOAP擴展，旨在消息交換相關方之間建立一個信任的關係（Trust Relationship）。在絕大部分場景下，這裏所指的信任關係是雙向而非單向的。站在消息交換的角度來講，信任關係不僅僅包括消息接收者對請求者的信任，也包括請求者對接收者的信任。要建立起彼此之間的信任關係，一個前提能夠互相驗證對方的真實身份，所以這裏也就涉及到一個雙向驗證的問題。

在Web服務的世界中，消息交換為通信的唯一手段，那麼相關方之間的信任關係的建立也隻能圍繞著消息交換來實現。定義在WS-Trust中的Web服務的信任模型基於這樣的處理機製：Web服務要求接收的消息中包含有能夠證明所需申明（包括身份、權限或者能力等）。如果Web服務接收到的消息不具有這些申明證明信息，它可以選擇忽略或者拒絕該消息。

在這裏，這些證明信息通過安全令牌（Security Token）的方式存在。實際上WS-Trust為我們提供了一種大體上的消息交換機製以實現安全令牌的頒發（Issuance）、續訂（Renewal）和終止（Cancel）等。至於具體采用的安全消息交換形式，則借助於WS-Security，所以WS-Trust實際上是建立在WS-Trust之上的。WS-Trust具有兩個主要的版本，即WS-Trust 1.3和WS-Trust 1.4，它們發布的時間分別是2005年和2008年。這兩個版本的WS-Trust對應的命名空間URI分別為https://docs.oasis-open.org/ws-sx/ws-trust/200512和https://docs.oasis-open.org/ws-sx/ws-trust/200802。以下的內容主要基於WS-Trust 1.4。

WS-SecurreConversation

通過上麵的介紹，我們知道安全傳輸旨在解決兩個方麵的問題，即身份認證和消息保護（消息的一致性和機密性）。我們假設這樣一個應用場景：客戶端和服務分別采用用戶名/密碼和X.509證書作為各自的用戶憑證，那麼針對於每一個單一的消息交換，可以通過下麵的方式解決上述兩個問題：

• 客戶端采用服務端證書的公鑰對消息進行加密，服務端在接收到消息的時候通過自己的私鑰進行解密；
• 客戶端每次服務調用均附加一個基於用戶名/密碼的安全令牌，服務端提取它對用以驗證訪問者的身份。

這好像是一個“完美”的解決方案，但是不知道你是否考慮過這樣一個問題：如果客戶端和服務端在一段時間內需要進行頻繁的通信，那麼性能問題就產生了。影響性能的因素主要包括：服務端需要對客戶端進行頻繁的認證；頻繁地進行非對稱加密/解密。

我們更加希望的是實現這樣的安全傳輸機製：客戶端和服務端在進行正式的消息交換之前，在它們之間通過彼此的認證，並建立起一個安全的上下文環境，或者說一個安全的會話。在這個上下文中，服務端無需對客戶端進行重複的認證。此外，一個僅在當前上下文中被雙方共享的密鑰被創建出來，采用對稱加密技術對消息進行簽名和加密。

這個機製基本類似於TLS/SSL,不過TLS/SSL隻是在傳輸層針對於數據段提供安全傳輸保障，而我們現在介紹的則是針對於SOAP消息的安全傳輸。由於這個機製主要為交互雙方在同一個上下文環境中的多次消息交換提供安全傳輸的保障，我們將其稱為Secure Conversation，OASIS為此製定了相應的規範，也就是我們本節要介紹的WS-SecureConversation。而WCF通過Secure Session機製提供對WS-SecureConversation的實現。

WS-SecureConversation具有兩個主要的版本，即1.3和1.4，分別在2007和2009年發布，以下的內容主要針對WS-SecureConversation 1.4。WS-SecureConversation建立在WS-Security和WS-Trust基礎之上，旨在提供一種機製對實現對安全上下文的創建和整個生命周期的控製。

我們目前提到的安全上下文（Security Context）僅僅是一種概念上的描述，而在真正的消息交換中，它通過一個具體的安全上下文令牌（SCT：Security Context Token）來表示。安全上下文令牌屬於一種特殊的安全令牌，而WS-Trust為我們定義了一套完整的安全令牌傳播機製。所以WS-SecureConversation完全借助於定義在WS-Trust的消息交換方式來完成針對安全上下文令牌的頒發（Issurance）、修複（Amending）、續訂（Renewal）和注銷（Cancel）。

WS-SecurityPolicy

一個Web服務（這裏指廣義的、與技術平台無關的Web服務）除了實現通過服務契約定義的業務功能之外，為了實現一些額外的功能（比如安全、事務和可靠傳輸等），還需要具有一些與業務無關的行為（Behavior）和能力（Capability），我們可以將這些統稱為Web服務的策略（Policy）。WS-Policy提供了一個基於XML的框架模型和語法用於描述Web服務的能力、要求和行為屬性。關於WS-Policy，在本書第二章有相應的介紹。

而這裏介紹的WS-SecurityPolicy則建立在WS-Policy基礎上，定義了一係列關於安全傳輸的策略斷言（Policy Assertion）。而這些策略斷言最終被應用在WS-Security、WS-Trust和WS-SecureConversation中。WS-SecurityPolicy具有兩個主要的版本，即WS-SecurityPolicy1.2和WS-SecurityPolicy1.3，發布時間分別為2007年和2009年。

到此為止，我們已經介紹了WS-*體係中關於安全的4個重要的規範，WS-Security、WS-Trust、WS-SecureConversation和WS-SecurityPolicy。而WCF的消息安全模式是這四個WS-*規範的實現者。如果你想深刻地理解WCF的安全體係，對這四個安全規範的了解是必須的，這也是我為何要花這麼的篇幅來介紹它們的原因。

但是處於篇幅的限製，這裏對僅僅提供對WS-Security、WS-Trust、WS-Secure Conversation和WS-Security Policy大體上的介紹。如果讀者對此有興趣，可以通過下麵的提供的地址下載下載官方文檔。

WS-Security 1.0：https://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
WS-Security 1.1(核心規範)：https://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf
WS-Trust 1.3：https://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf
WS-Trust 1.4：https://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/ws-trust-1.4-spec-os.pdf
WS-SecureConversation 1.3：https://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversation-1.3-os.pdf
WS-SecureConversation 1.4：https://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.pdf
WS-SecurityPolicy 1.2：https://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf
WS-SecurityPolicy 1.3：https://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf

Message安全模式的優缺點

關於WCF的Message安全模式的優點，實際上在前麵已經有所提及，在這裏做一個總結。總的來說，較之Transport安全模式，Message安全模式具有如下的優點：

• 由於Message安全模式是通過在應用層通過對消息實施加密、簽名等安全機製實現的，所以這是一種於具體傳輸協議無關的安全機製，不會因底層采用的是TCP或者HTTP而有所不同。較之Transport安全，這種基於應用層實現的安全機製在認證方式上具有更多的選擇；
• 由於Message安全模式下各種安全機製都是直接應用在消息（SOAP）級別的，無論消息路由的路徑有多複雜，都能夠保證消息的安全傳輸。所以，不同於Transport安全模式隻能提供點對點（Point-to-Point）的安全，Message安全模式能夠提供端到端（End-to-End）安全；
• 由於Message安全模式是對WS-Security、WS-Trust、WS-SecureConversation和WS-SecurityPolicy這四個WS-*規範的實現，所有具有很好的互操作性，能夠提供跨平台的支持。

但是Transport安全模式有一點是Message安全模式不能比的，那就是性能。Transport安全模式能夠借助於網絡適配器硬件加速，降低CPU計算時間，從而提供高效的傳輸安全。Message模式在性能上稍遜一籌。

由於WCF的兩種安全模式，即Transport和Message安全模式，都具有各自的優缺點，我們通過兩者的結合構成一種混合的安全傳輸解決方案。我們稱之為混合（Mixed）的安全模式。那麼，這種新的安全模式是如何對Transport和Message安全模式進行“混合”呢？

我們知道，安全傳輸旨在解決三個問題：認證、消息一致性和機密性，而認證既包括服務端對客戶端的認證，也包括客戶端對服務端的認證。對於混合安全模式，消息的一致性、機密性和客戶端對服務端的認證通過Transport安全模式來實現，而采用Message安全模式實現服務端對客戶端的認證。

混合（以下簡稱Mixed）安全模式充分利用了Transport安全模式硬件加速優勢，以提供高性能和具有高吞吐量的服務。由於服務端對客戶端的驗證是通過Message安全模式來實現的，所以我們具有更多關於客戶端安全憑證和認證方式的選擇。此外，由於Transport安全模式不可回避的極限性，混合安全模式也隻能提供點到點的安全。

作者：蔣金楠
微信公眾賬號：大內老A
微博：www.weibo.com/artech
如果你想及時得到個人撰寫文章以及著作的消息推送，或者想看看個人推薦的技術資料，可以掃描左邊二維碼（或者長按識別二維碼）關注個人公眾號（原來公眾帳號蔣金楠的自媒體將會停用）。
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁麵明顯位置給出原文連接，否則保留追究法律責任的權利。

原文鏈接