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安全模式

顧名思義，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安全模式。

二、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分別為和。以下的內容主要基於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：http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf    
WS-Security 1.1(核心規範)：http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf    
WS-Trust 1.3：/ws-trust-1.3-os.pdf    
WS-Trust 1.4：    
WS-SecureConversation 1.3：http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversation-1.3-os.pdf    
WS-SecureConversation 1.4：http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.pdf    
WS-SecurityPolicy 1.2：http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf    
WS-SecurityPolicy 1.3：http://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模式在效能上稍遜一籌。

三、複合安全模式（Mixed Security Mode）

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

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

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