WCF的安全體系主要包括三個(gè)方面：傳輸安全、授權(quán)或者訪問(wèn)控制以及審核。而傳輸安全又包括兩個(gè)方面：認(rèn)證和消息保護(hù)。認(rèn)證幫助客戶端或者服務(wù)確認(rèn)對(duì)方的真實(shí)身份，而消息保護(hù)則通過(guò)簽名和加密實(shí)現(xiàn)消息的一致性和機(jī)密性。WCF采用兩種不同的機(jī)制來(lái)解決這三個(gè)涉及到傳輸安全的問(wèn)題，我們一般將它們稱為不同的安全模式，即Transport安全模式和Message安全模式。

WCF的安全體系主要包括三個(gè)方面：傳輸安全（Transfer Security）、授權(quán)或者訪問(wèn)控制（Authorization OR Access Control）以及審核（Auditing）。而傳輸安全又包括兩個(gè)方面：認(rèn)證（Authentication）和消息保護(hù)（Message Protection）。認(rèn)證幫助客戶端或者服務(wù)確認(rèn)對(duì)方的真實(shí)身份，而消息保護(hù)則通過(guò)簽名和加密實(shí)現(xiàn)消息的一致性和機(jī)密性。WCF采用兩種不同的機(jī)制來(lái)解決這三個(gè)涉及到傳輸安全的問(wèn)題，我們一般將它們稱為不同的安全模式，即Transport安全模式和Message安全模式。

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

注：由于英文中的Transfer Security和Transport Security都可以翻譯成傳輸安全，以示區(qū)別，我用中文的“傳輸安全”表示涉及到認(rèn)證、消息一致性和機(jī)密性的Transfer Security，而采用“Transport安全（模式）”表示基于某種網(wǎng)絡(luò)協(xié)議的傳輸層安全（模式），與“Transport安全（模式）”相對(duì)的是“Message安全（模式）”。

一、Transport安全模式

顧名思義，Transport安全模式就是利用基于傳輸層協(xié)議的安全機(jī)制解決傳輸安全涉及的三個(gè)問(wèn)題，即認(rèn)證、消息一致性和進(jìn)行性。而TLS/SSL是實(shí)現(xiàn)Transport安全最常用（并非唯一）的方式。

TLS、SSL和HTTPS

任何一本介紹WCF的書，在介紹Transport安全模式的時(shí)候，必然會(huì)提到SSL或者HTTPS，有時(shí)還會(huì)提到TLS。有一些人不太明白這三者到底有什么區(qū)別，尤其是不能很好的區(qū)分TLS和SSL的差別。在這里，我們就先來(lái)簡(jiǎn)單介紹一下這三個(gè)相關(guān)的概念。

SSL（Secure Sockets Layer）最初是由Netscape公司開(kāi)發(fā)的一種安全協(xié)議，應(yīng)用于Netscape瀏覽器以解決與Web服務(wù)器之間的安全傳輸問(wèn)題。SSL先后經(jīng)歷了三個(gè)主要的版本，即1.0、2.0和3.0。之后SSL被IETF （Internet Engineering Task Force）接管，正是根名為TLS（Transport Layer Security）。可以這么說(shuō)，SSL是TLS的前身，TLS 1.0相當(dāng)于SSL 3.1。

TLS/SSL本身是和具體的網(wǎng)絡(luò)傳輸協(xié)議無(wú)關(guān)的，既可以用于HTTP，也可以用于TCP。而HTTPS（Hypertext Transfer Protocol Secure）則是將HTTP和TLS/SSL兩者結(jié)合起來(lái)。在一般情況下，HTTPS通常采用443端口進(jìn)行通信。對(duì)于WCF來(lái)說(shuō)，所以基于HTTP協(xié)議的綁定的Transport安全都是通過(guò)HTTPS來(lái)實(shí)現(xiàn)的。而NetTcpBinding和NetNamedPipeBinding也提供了對(duì)TLS/SSL的支持，一般我們將TLS/SSL在TCP上的應(yīng)用稱為SSL Over TCP。

TLS/SSL幫助我們解決兩個(gè)問(wèn)題：客戶端對(duì)服務(wù)端的驗(yàn)證，以及通過(guò)對(duì)傳輸層傳輸?shù)臄?shù)據(jù)段（Segment）進(jìn)行加密確保消息的機(jī)密性。出于性能的考慮，這里采用的是對(duì)稱加密而不是非對(duì)稱加密。接下來(lái)，我從消息交換的角度來(lái)說(shuō)明上述的兩個(gè)問(wèn)題是如何通過(guò)TLS/SSL解決的。

我們以訪問(wèn)一個(gè)HTTPS站點(diǎn)為例。當(dāng)客戶端和這個(gè)HTTPS站點(diǎn)所在的Web服務(wù)器進(jìn)行正式的訪問(wèn)請(qǐng)求之前，在它們之間必須建立了安全的HTTP連接。而這樣一個(gè)安全的連接的創(chuàng)建通過(guò)客戶端和Web站點(diǎn)之間的多次握手或者協(xié)商（Negotiation）來(lái)完成。如下圖示，整個(gè)協(xié)商過(guò)程主要包括三個(gè)步驟。

步驟一：客戶端向HTTPS站點(diǎn)發(fā)送協(xié)商請(qǐng)求，該請(qǐng)求中包括客戶端所能夠支持的加密算法列表；

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

步驟三：客戶端接收到服務(wù)端發(fā)回的數(shù)字證書之后，通過(guò)驗(yàn)證證書進(jìn)而確定服務(wù)身份。在驗(yàn)證成功的情況下，客戶端會(huì)生成一個(gè)隨機(jī)隨機(jī)數(shù)，作為會(huì)話密鑰（Session Key），緩存在客戶端。客戶端隨后并采用服務(wù)端發(fā)回的加密算法，利用從證書中提取的公鑰進(jìn)行加密。加密后的會(huì)話密鑰被發(fā)送給服務(wù)端，服務(wù)端使用自己的私鑰采用相對(duì)應(yīng)的算法進(jìn)行機(jī)密得到該會(huì)話密鑰。至此，客戶端和服務(wù)端具有一個(gè)只有它們彼此知曉的會(huì)話密鑰，所有的請(qǐng)求和回復(fù)消息均通過(guò)該會(huì)化密鑰進(jìn)行加密和解密。

有人可能會(huì)說(shuō)，客戶端為何不直接用從數(shù)字證書提取的公鑰對(duì)所有的請(qǐng)求消息進(jìn)行加密，服務(wù)端采用私鑰進(jìn)行解密。之所以選擇對(duì)稱加密而不是非對(duì)稱加密，主要有兩方面的原因：

• 對(duì)稱加密/解密比非對(duì)稱加密/解密需要更少的計(jì)算，所以具有更好的性能；
• 上述的加密方式只能確?？蛻舳讼蚍?wù)端請(qǐng)求消息的機(jī)密性，而不能保證服務(wù)端向客戶端回復(fù)消息的機(jī)密性。

Transport安全模型的優(yōu)缺點(diǎn)

較之我們后續(xù)介紹的Message安全模式，Transport安全模式具有一個(gè)最到的優(yōu)點(diǎn)，那就是高性能。雖然TLS/SSL在正式進(jìn)行消息交換之前需要通過(guò)協(xié)商建立一個(gè)安全的連接，但是這個(gè)協(xié)商過(guò)程完全通過(guò)傳輸層協(xié)議來(lái)完成。而且這種安全模式還可以充分利用網(wǎng)絡(luò)適配器的硬件加速，這樣就可以介紹CPU時(shí)間，進(jìn)而提供性能。但是，受限于傳輸層安全協(xié)議的特點(diǎn)，Transport安全模式也具有一些不可避免的局限性：

• Transport安全模式依賴于具體的傳輸協(xié)議；
• 它只能提供基于點(diǎn)對(duì)點(diǎn)（Point-to-Point）的安全傳輸保障，即客戶端之間連接服務(wù)的場(chǎng)景。如果在客戶端的服務(wù)端之間的網(wǎng)絡(luò)需要一些用于消息路由的中間結(jié)點(diǎn)，Transport安全模式則沒(méi)有了用武之地。
• 在Transport安全模式下，意味著我們不得不在傳輸層而不能在應(yīng)用層解決對(duì)客戶端的認(rèn)證，這就決定了可供選擇的認(rèn)證方式不如Message模式多。

也正是由于上述的這些局限（主要還是只能提供點(diǎn)對(duì)點(diǎn)的安全傳輸保障），決定了Intranet是Transport安全模式主要的應(yīng)用環(huán)境。為了克服這些局限，我們需要一種與傳輸協(xié)議無(wú)關(guān)的、能夠提供端到端（End-to-End）安全傳輸保障的、具有多種認(rèn)證解決方案的安全模式，那就是Message安全模式。

二、Message安全模式

Transport安全模式將安全傳輸策略應(yīng)用到傳輸層的數(shù)據(jù)段，進(jìn)而間接地實(shí)現(xiàn)基于消息的安全傳輸。而Message模式則直接將安全策略的目標(biāo)對(duì)象對(duì)準(zhǔn)消息本身，通過(guò)對(duì)消息進(jìn)行簽名、加密實(shí)現(xiàn)消息安全傳輸。所以Message安全模式不會(huì)因底層是HTTP或者TCP傳輸協(xié)議而采用不同的安全機(jī)制，并且能夠提供從消息最初發(fā)送端到最終接收端之間的安全傳輸，即端到端（End-To-End）安全傳輸。Message模式下的安全協(xié)議是一種應(yīng)用層協(xié)議，我們可以在應(yīng)用層上實(shí)現(xiàn)對(duì)客戶端的驗(yàn)證，因而具有更多的認(rèn)證解決方案的選擇。

此外， WCF的Message安全模式并不是微軟在Windows平臺(tái)下的閉門造車，而是遵循一系列開(kāi)放的標(biāo)準(zhǔn)或者規(guī)范，那就是圍繞著WS-Security的四個(gè)WS-*規(guī)范，即WS-Trust、WS-Secure Conversation和WS-Security Policy。這就意味著WCF的Message安全具有很好的互操作性或平臺(tái)無(wú)關(guān)性。

WS-Security

WS-Security由是由結(jié)構(gòu)化信息標(biāo)準(zhǔn)促進(jìn)組織（OASIS：Organization for the Advancement of Structured Information Standards）制定。對(duì)于本書的讀者來(lái)說(shuō)，我相信你應(yīng)該不會(huì)對(duì)OASIS這個(gè)組織感到陌生了吧。不僅僅是WS-Security，包括我們接下來(lái)要介紹的WS-Trust、WS-Secure Conversation和WS-Security Policy，它們的制定者也是這個(gè)標(biāo)準(zhǔn)組織。

WS-Security，有時(shí)候又被簡(jiǎn)稱為WSS，制定了一整套標(biāo)準(zhǔn)的基于SOAP（包括SOAP 1.1和SOAP 1.2）的擴(kuò)展以幫助創(chuàng)建一個(gè)安全的Web服務(wù)。到目前為止，OASIS推出了兩個(gè)版本，第一個(gè)正式的版本于2004年3月發(fā)布，即WS-Security 1.0，有時(shí)候被稱為WS-Security 2004。2006年2月，OASIS發(fā)布了WS-Security 1.1。

定義在WS-Security中的SOAP的安全機(jī)制可以廣泛地應(yīng)用于現(xiàn)有的多種安全模式下，比如PKI、Kerberos和SSL等。WS-Security支持多種安全令牌（Security Token）格式（比如用戶名/密碼、SAML、X509證書和Kerberos票據(jù)等）、多種簽名格式和加密技術(shù)。針對(duì)具體的安全令牌，WS-Security通過(guò)對(duì)應(yīng)的Profile文檔進(jìn)行單獨(dú)定義。

WS-Security提供了關(guān)于SOAP安全交換的三個(gè)主要機(jī)制：如何將安全令牌作為消息的一部分進(jìn)行傳輸，如何檢測(cè)接收到的消息是否和原始發(fā)送的一致，以及如何確保消息的真實(shí)內(nèi)容僅對(duì)真正的接收者可見(jiàn)。安全令牌的傳輸主要解決身份認(rèn)證的問(wèn)題，所以這三個(gè)方面就是傳輸安全面對(duì)的三個(gè)問(wèn)題：身份認(rèn)證、消息一致性和消息機(jī)密性。WS-Security提供了一個(gè)抽象的消息安全模型。在這個(gè)安全模型中，通過(guò)安全令牌，結(jié)合數(shù)字簽名和加密技術(shù)實(shí)現(xiàn)對(duì)消息交換實(shí)體的認(rèn)證和對(duì)消息本身的保護(hù)。

WS-Trust

WS-Trust通過(guò)定義了一系列SOAP擴(kuò)展，旨在消息交換相關(guān)方之間建立一個(gè)信任的關(guān)系（Trust Relationship）。在絕大部分場(chǎng)景下，這里所指的信任關(guān)系是雙向而非單向的。站在消息交換的角度來(lái)講，信任關(guān)系不僅僅包括消息接收者對(duì)請(qǐng)求者的信任，也包括請(qǐng)求者對(duì)接收者的信任。要建立起彼此之間的信任關(guān)系，一個(gè)前提能夠互相驗(yàn)證對(duì)方的真實(shí)身份，所以這里也就涉及到一個(gè)雙向驗(yàn)證的問(wèn)題。

在Web服務(wù)的世界中，消息交換為通信的唯一手段，那么相關(guān)方之間的信任關(guān)系的建立也只能圍繞著消息交換來(lái)實(shí)現(xiàn)。定義在WS-Trust中的Web服務(wù)的信任模型基于這樣的處理機(jī)制：Web服務(wù)要求接收的消息中包含有能夠證明所需申明（包括身份、權(quán)限或者能力等）。如果Web服務(wù)接收到的消息不具有這些申明證明信息，它可以選擇忽略或者拒絕該消息。

在這里，這些證明信息通過(guò)安全令牌（Security Token）的方式存在。實(shí)際上WS-Trust為我們提供了一種大體上的消息交換機(jī)制以實(shí)現(xiàn)安全令牌的頒發(fā)（Issuance）、續(xù)訂（Renewal）和終止（Cancel）等。至于具體采用的安全消息交換形式，則借助于WS-Security，所以WS-Trust實(shí)際上是建立在WS-Trust之上的。WS-Trust具有兩個(gè)主要的版本，即WS-Trust 1.3和WS-Trust 1.4，它們發(fā)布的時(shí)間分別是2005年和2008年。這兩個(gè)版本的WS-Trust對(duì)應(yīng)的命名空間URI分別為http://docs.oasis-open.org/ws-sx/ws-trust/200512和http://docs.oasis-open.org/ws-sx/ws-trust/200802。以下的內(nèi)容主要基于WS-Trust 1.4。

WS-SecurreConversation

通過(guò)上面的介紹，我們知道安全傳輸旨在解決兩個(gè)方面的問(wèn)題，即身份認(rèn)證和消息保護(hù)（消息的一致性和機(jī)密性）。我們假設(shè)這樣一個(gè)應(yīng)用場(chǎng)景：客戶端和服務(wù)分別采用用戶名/密碼和X.509證書作為各自的用戶憑證，那么針對(duì)于每一個(gè)單一的消息交換，可以通過(guò)下面的方式解決上述兩個(gè)問(wèn)題：

• 客戶端采用服務(wù)端證書的公鑰對(duì)消息進(jìn)行加密，服務(wù)端在接收到消息的時(shí)候通過(guò)自己的私鑰進(jìn)行解密；
• 客戶端每次服務(wù)調(diào)用均附加一個(gè)基于用戶名/密碼的安全令牌，服務(wù)端提取它對(duì)用以驗(yàn)證訪問(wèn)者的身份。

這好像是一個(gè)“完美”的解決方案，但是不知道你是否考慮過(guò)這樣一個(gè)問(wèn)題：如果客戶端和服務(wù)端在一段時(shí)間內(nèi)需要進(jìn)行頻繁的通信，那么性能問(wèn)題就產(chǎn)生了。影響性能的因素主要包括：服務(wù)端需要對(duì)客戶端進(jìn)行頻繁的認(rèn)證；頻繁地進(jìn)行非對(duì)稱加密/解密。

我們更加希望的是實(shí)現(xiàn)這樣的安全傳輸機(jī)制：客戶端和服務(wù)端在進(jìn)行正式的消息交換之前，在它們之間通過(guò)彼此的認(rèn)證，并建立起一個(gè)安全的上下文環(huán)境，或者說(shuō)一個(gè)安全的會(huì)話。在這個(gè)上下文中，服務(wù)端無(wú)需對(duì)客戶端進(jìn)行重復(fù)的認(rèn)證。此外，一個(gè)僅在當(dāng)前上下文中被雙方共享的密鑰被創(chuàng)建出來(lái)，采用對(duì)稱加密技術(shù)對(duì)消息進(jìn)行簽名和加密。

這個(gè)機(jī)制基本類似于TLS/SSL,不過(guò)TLS/SSL只是在傳輸層針對(duì)于數(shù)據(jù)段提供安全傳輸保障，而我們現(xiàn)在介紹的則是針對(duì)于SOAP消息的安全傳輸。由于這個(gè)機(jī)制主要為交互雙方在同一個(gè)上下文環(huán)境中的多次消息交換提供安全傳輸?shù)谋Ｕ?，我們將其稱為Secure Conversation，OASIS為此制定了相應(yīng)的規(guī)范，也就是我們本節(jié)要介紹的WS-SecureConversation。而WCF通過(guò)Secure Session機(jī)制提供對(duì)WS-SecureConversation的實(shí)現(xiàn)。

WS-SecureConversation具有兩個(gè)主要的版本，即1.3和1.4，分別在2007和2009年發(fā)布，以下的內(nèi)容主要針對(duì)WS-SecureConversation 1.4。WS-SecureConversation建立在WS-Security和WS-Trust基礎(chǔ)之上，旨在提供一種機(jī)制對(duì)實(shí)現(xiàn)對(duì)安全上下文的創(chuàng)建和整個(gè)生命周期的控制。

我們目前提到的安全上下文（Security Context）僅僅是一種概念上的描述，而在真正的消息交換中，它通過(guò)一個(gè)具體的安全上下文令牌（SCT：Security Context Token）來(lái)表示。安全上下文令牌屬于一種特殊的安全令牌，而WS-Trust為我們定義了一套完整的安全令牌傳播機(jī)制。所以WS-SecureConversation完全借助于定義在WS-Trust的消息交換方式來(lái)完成針對(duì)安全上下文令牌的頒發(fā)（Issurance）、修復(fù)（Amending）、續(xù)訂（Renewal）和注銷（Cancel）。

WS-SecurityPolicy

一個(gè)Web服務(wù)（這里指廣義的、與技術(shù)平臺(tái)無(wú)關(guān)的Web服務(wù)）除了實(shí)現(xiàn)通過(guò)服務(wù)契約定義的業(yè)務(wù)功能之外，為了實(shí)現(xiàn)一些額外的功能（比如安全、事務(wù)和可靠傳輸?shù)龋€需要具有一些與業(yè)務(wù)無(wú)關(guān)的行為（Behavior）和能力（Capability），我們可以將這些統(tǒng)稱為Web服務(wù)的策略（Policy）。WS-Policy提供了一個(gè)基于XML的框架模型和語(yǔ)法用于描述Web服務(wù)的能力、要求和行為屬性。關(guān)于WS-Policy，在本書第二章有相應(yīng)的介紹。

而這里介紹的WS-SecurityPolicy則建立在WS-Policy基礎(chǔ)上，定義了一系列關(guān)于安全傳輸?shù)牟呗詳嘌裕≒olicy Assertion）。而這些策略斷言最終被應(yīng)用在WS-Security、WS-Trust和WS-SecureConversation中。WS-SecurityPolicy具有兩個(gè)主要的版本，即WS-SecurityPolicy1.2和WS-SecurityPolicy1.3，發(fā)布時(shí)間分別為2007年和2009年。

到此為止，我們已經(jīng)介紹了WS-*體系中關(guān)于安全的4個(gè)重要的規(guī)范，WS-Security、WS-Trust、WS-SecureConversation和WS-SecurityPolicy。而WCF的消息安全模式是這四個(gè)WS-*規(guī)范的實(shí)現(xiàn)者。如果你想深刻地理解WCF的安全體系，對(duì)這四個(gè)安全規(guī)范的了解是必須的，這也是我為何要花這么的篇幅來(lái)介紹它們的原因。

但是處于篇幅的限制，這里對(duì)僅僅提供對(duì)WS-Security、WS-Trust、WS-Secure Conversation和WS-Security Policy大體上的介紹。如果讀者對(duì)此有興趣，可以通過(guò)下面的提供的地址下載下載官方文檔。

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(核心規(guī)范)：http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf
WS-Trust 1.3：http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf
WS-Trust 1.4：http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/ws-trust-1.4-spec-os.pdf
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安全模式的優(yōu)缺點(diǎn)

關(guān)于WCF的Message安全模式的優(yōu)點(diǎn)，實(shí)際上在前面已經(jīng)有所提及，在這里做一個(gè)總結(jié)?？偟膩?lái)說(shuō)，較之Transport安全模式，Message安全模式具有如下的優(yōu)點(diǎn)：

• 由于Message安全模式是通過(guò)在應(yīng)用層通過(guò)對(duì)消息實(shí)施加密、簽名等安全機(jī)制實(shí)現(xiàn)的，所以這是一種于具體傳輸協(xié)議無(wú)關(guān)的安全機(jī)制，不會(huì)因底層采用的是TCP或者HTTP而有所不同。較之Transport安全，這種基于應(yīng)用層實(shí)現(xiàn)的安全機(jī)制在認(rèn)證方式上具有更多的選擇；
• 由于Message安全模式下各種安全機(jī)制都是直接應(yīng)用在消息（SOAP）級(jí)別的，無(wú)論消息路由的路徑有多復(fù)雜，都能夠保證消息的安全傳輸。所以，不同于Transport安全模式只能提供點(diǎn)對(duì)點(diǎn)（Point-to-Point）的安全，Message安全模式能夠提供端到端（End-to-End）安全；
• 由于Message安全模式是對(duì)WS-Security、WS-Trust、WS-SecureConversation和WS-SecurityPolicy這四個(gè)WS-*規(guī)范的實(shí)現(xiàn)，所有具有很好的互操作性，能夠提供跨平臺(tái)的支持。

但是Transport安全模式有一點(diǎn)是Message安全模式不能比的，那就是性能。Transport安全模式能夠借助于網(wǎng)絡(luò)適配器硬件加速，降低CPU計(jì)算時(shí)間，從而提供高效的傳輸安全。Message模式在性能上稍遜一籌。

三、復(fù)合安全模式（Mixed Security Mode）

由于WCF的兩種安全模式，即Transport和Message安全模式，都具有各自的優(yōu)缺點(diǎn)，我們通過(guò)兩者的結(jié)合構(gòu)成一種混合的安全傳輸解決方案。我們稱之為混合（Mixed）的安全模式。那么，這種新的安全模式是如何對(duì)Transport和Message安全模式進(jìn)行“混合”呢？

我們知道，安全傳輸旨在解決三個(gè)問(wèn)題：認(rèn)證、消息一致性和機(jī)密性，而認(rèn)證既包括服務(wù)端對(duì)客戶端的認(rèn)證，也包括客戶端對(duì)服務(wù)端的認(rèn)證。對(duì)于混合安全模式，消息的一致性、機(jī)密性和客戶端對(duì)服務(wù)端的認(rèn)證通過(guò)Transport安全模式來(lái)實(shí)現(xiàn)，而采用Message安全模式實(shí)現(xiàn)服務(wù)端對(duì)客戶端的認(rèn)證。

混合（以下簡(jiǎn)稱Mixed）安全模式充分利用了Transport安全模式硬件加速優(yōu)勢(shì)，以提供高性能和具有高吞吐量的服務(wù)。由于服務(wù)端對(duì)客戶端的驗(yàn)證是通過(guò)Message安全模式來(lái)實(shí)現(xiàn)的，所以我們具有更多關(guān)于客戶端安全憑證和認(rèn)證方式的選擇。此外，由于Transport安全模式不可回避的極限性，混合安全模式也只能提供點(diǎn)到點(diǎn)的安全。