許多 WS-Security 配置要求客戶端和服務器都使用 public/private 密鑰對，使用 X.509 證書保證公共密鑰的身份。這是使用 WS-Security 進行消息簽名或加密中最廣泛使用的技術，而且它有一些優勢。特別地，客戶端證書對請求提供了較嚴格的客戶端身份驗證和較嚴格的簽名保證。但是它也有缺點，包括不對稱加密的性能開銷和每個客戶端獲取和維護證書的繁瑣管理。
“WS-SecureConversation 性能” 介紹 WS-SecureConversation — 雖然仍然使用客戶端證書 — 是如何使用對稱加密來減少客戶端和服務器之間持續交換消息的性能開銷。在本文中，您將會了解您可以如何更一步地打破在普通的 WS-Security 和 WS-SecureConversation 交換方面都需要客戶端證書的現狀。
不需要客戶端證書的加密和簽名
使用不對稱加密和 public/private 密鑰對進行消息的簽名和加密是很簡單的（至少概念上很簡單）。正如在 “Axis2 WS-Security 簽名和加密” 中所介紹的，您可以使用您的私鑰對消息進行簽名，並使用接收者的公鑰對消息進行加密。任何得到您的公鑰（一般以 X.509 證書的形式封裝在多層認證中）的人都可以驗證您使用私鑰生成的簽名，但是只有對應私鑰的擁有者才能夠解密使用公鑰加密的消息。
如果客戶端沒有 public/private 密鑰對，您就無法使用完整的不對稱加密技術。另外一種方法是對稱加密，但是使用對稱加密時，您必須擁有只有參與消息交換各方才知道的密鑰。您可以如何創建這樣一個保密密鑰呢？
WS-Security 所使用的技術是要使客戶端生成一個保密密鑰值，然後再使用不對稱加密和服務器公鑰對它進行加密，並將它嵌入到一個 <xenc:EncryptedKey> 令牌的請求消息中。客戶端可以使用這個保密密鑰（或者更安全的做法是使用由保密密鑰生成的單獨密鑰）來對請求消息進行加密和/或簽名，而服務器也可以對響應消息做相同的操作。服務器不需要將保密密鑰發送回客戶端，因為客戶端已經擁有了這個保密密鑰。
WS-SecurityPolicy 配置
使用客戶端生成密鑰的對稱加密的 WS-Policy/WS-SecurityPolicy 配置是很簡單的。清單 1 顯示的是本文所使用的版本。這個策略使用客戶端生成的保密密鑰來規定發送到兩個方向的消息體加密方式。
清單 1. 用於加密所有消息體的 WS-Policy
<wsp:Policy wsu:Id="SymmEncr"
xmlns:wsu="http://.../oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:ExactlyOne>
<wsp:All>
<sp:SymmetricBinding>
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Never">
<wsp:Policy>
<sp:RequireDerivedKeys/>
<sp:RequireThumbprintReference/>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:ProtectionToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128Rsa15/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict/>
</wsp:Policy>
</sp:Layout>
</wsp:Policy>
</sp:SymmetricBinding>
<sp:Wss11>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefThumbprint/>
<sp:MustSupportRefEncryptedKey/>
</wsp:Policy>
</sp:Wss11>
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
清單 1 策略中的 <sp:SymmetricBinding> 斷言是配置使用帶有保密密鑰的對稱加密的代碼。所嵌入的 <sp:X509Token> 斷言表示有一個 X.509 證書將用於保護保密密鑰的傳輸（即，加密所傳輸的保密密鑰），而這是使用指紋引用（本質上是一個散列值）識別的證書。客戶端生成的保密密鑰是隱式使用帶有 <sp:X509Token> 保護令牌的 <sp:SymmetricBinding> 斷言。其他策略斷言則規定了加密算法的細節和必要的特性，而最終 <sp:EncryptedParts> 斷言表示將要使用保密密鑰進行加密的 SOAP Body。
正如您在之前的文章中看到的，安全性處理的運行時參數（如密鑰保存和密碼）必須采用與實現無關的方式進行定義。在這裡，這些參數是很簡單的：客戶端需要訪問包含服務器證書的可信存儲，而服務器端則需要訪問包含證書中與公鑰相匹配的私有密鑰的密鑰存儲。請閱讀這個 系列文章 了解參數在各個協議之間是如何傳遞的。
不使用客戶端證書的 WS-SecureConversation
在使用 WS-SecureConversation 時，您可以使用相同的技術在沒有客戶端證書的情況下處理客戶端和 Security Token Service (STS) 之間的消息交換。（閱讀 “WS-Trust 和 WS-SecureConversation” 和 “WS-SecureConversation 性能” 了解 WS-SecureConversation 的細節。）要使用這種方法，您基本上需要將 清單 1 的策略替換為 <sp:BootstrapPolicy>，以實現安全會話。清單 2 顯示了這是如何工作的，它用粗體顯示的 <sp:SymmetricBinding> 替換 “WS-SecureConversation 性能” 中使用的 <sp:AsymmetricBinding>：
清單 2. WS-SecureConversation 中不使用客戶端證書的 WS-Policy
<wsp:Policy wsu:Id="SecureConv"
xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp:ExactlyOne>
<wsp:All>
<sp:SymmetricBinding>
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:SecureConversationToken
sp:IncludeToken=".../IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:BootstrapPolicy>
<wsp:Policy>
<sp:SymmetricBinding>
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Never">
<wsp:Policy>
<sp:RequireDerivedKeys/>
<sp:RequireThumbprintReference/>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:ProtectionToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128Rsa15/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict/>
</wsp:Policy>
</sp:Layout>
</wsp:Policy>
</sp:SymmetricBinding>
<sp:Wss11>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefThumbprint/>
<sp:MustSupportRefEncryptedKey/>
</wsp:Policy>
</sp:Wss11>
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
</wsp:Policy>
</sp:BootstrapPolicy>
</wsp:Policy>
</sp:SecureConversationToken>
</wsp:Policy>
</sp:ProtectionToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128Rsa15/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict/>
</wsp:Policy>
</sp:Layout>
</wsp:Policy>
</sp:SymmetricBinding>
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
除了使用客戶端生成的使用 STS 進行消息交換的密鑰，通過去除 <wsap:UsingAddressing> 斷言， 清單 2 中的策略也與 “WS-SecureConversation 性能” 中所使用的不同。
理論上，這個策略可以處理任何的 WS-Security 和 WS-SecureConversation 實現。實踐中，當我在三個主流開源 Java Web Service 工具嘗試這個配置時遇到了一些問題。CXF 是唯一能夠正常運行所編寫的策略的工具。Axis2 完全不能運行，它在處理 STS 響應消息時會出現客戶端異常錯誤。當我將輔助程序策略修改回不對稱加密方式時，Axis2 能夠運行，但是它在所有消息上使用 WS-Addressing。Metro 也會出錯；在我重新添加 <wsap:UsingAddressing> 時，它能夠處理客戶端為 STS 消息傳遞的對稱加密所生成的密鑰。
性能比較
性能比較使用與之前文章相同的測試代碼，即地震數據查詢服務。這個服務使用了幾年裡全世界所發生的超過 93,000 次地震的數據庫。發向服務的請求指定了一個時間范圍和地理坐標范圍，而這個服務將返回所指定范圍的所有地震數據。請閱讀 “WS-Security 的大開銷” 了解更多關於這個測試應用和示例請求/響應消息對的詳細信息。
在之前的文章中，性能測試使用了兩組請求序列。第一組使用了 1,000 個請求，其中查詢參數被調整為只匹配整個地震數據庫的一小部分（1,000 個請求只返回 816 個匹配的地震）。第二組使用了 100 個請求，其中查詢參數被調整為匹配更大范圍的數據庫（100 個請求只返回 176,745 個匹配的地震）。這兩個請求序列側重於 Web Services 協議的不同性能特征。第一個顯示這些協議處理包含少量數據的請求的速度有多快，而第二個強調處理數據容量的速度。每一個請求序列都會以不同的安全性配置多次運行，而結果只保存每一種配置的最短時間。而這一次，我們只測試兩個安全性配置：
使用 SymmetricBinding 加密所有的請求/響應消息體的 WS-Security （direct）
加密所有請求/響應消息體的 WS-SecureConversation（securconv）
securconv 配置本質上與 “WS-SecureConversation 性能” 中所使用的配置是相同的，唯一的區別是它在 Metro 和 CXF 的客戶端和 STS 之間的消息交換中使用了 SymmetricBinding。因為所測試的 SymmetricBinding STS 策略不能在 Axis2 中運行，用於計時測試的 Axis2 配置與前一篇文章所使用的是相同的。在策略中使用 SymmetricBinding 的變化更多是出於演示的目標，而不會對性能帶來重要影響，所以這個區別不會影響到結果。
這些測試是在運行 Mandriva 2009.1 32-bit Linux® 的筆記本電腦上的，它使用了 Turion X2 ZM-85 處理器，有 3GB 的 RAM，安裝了 Sun (Oracle) Java 1.6.0_10 32-bit JVM。（注意，它與前面文章的性能測試所使用的系統不一樣。）服務器代碼運行在 Tomcat 6.0.20 上，它的配置使用 1024MB 的堆，其中客戶端代碼使用 512MB 的堆。所測試的 Web Services 工具版本如下：
Axis2 1.5.1 和 Rampart 1.5
Metro 2.0
CXF 2.1.8
如果您想要在您自己的主機和 JVM 上進行這些測試，您可以從這裡 下載 代碼。
性能測試結果
圖 1 顯示了在小響應測試中所測得的時間。正如 “WS-SecureConversation 性能” 所介紹的，在 WS-SecureConversation 計時中 Metro 比 CXF 稍微快一些（大約快 10%）。Metro 甚至比直接使用對稱加密實現 WS-Security 還要快一些，大約快 30%。（在本文的兩個圖表中，較短的數據條表示更快一些的時間）。
圖 1. 使用小響應的測試時間
Axis2 的測試結果沒有包含在 圖 1 中，因為測試過程中出現了一個問題。Axis2 一開始的運行速度是可接受的，然後隨著循環次數的增加，速度明顯變慢。使用 Axis2 運行這個測試的總時間最後超過 Metro 的 40 倍。這種類型的變慢通常表示出現了問題，如由代碼所存儲值的線性查找，這裡錯誤出現在 Axis2 對於對稱加密的安全性處理中（可能是在處理客戶端生成的密鑰時，因為每一個請求都會生成一個新的保密密鑰）。
圖 2 顯示了大響應測試所測得的時間。這裡 Metro 又一次是運行最快的，但是 CXF 的速度很接近 — 兩者的區別只有 10%。Axis2 比其他兩種工具速度慢很多，這和之前文章中所介紹的 WS-Security 和 WS-SecureConversation 測試是一樣的。
圖 2. 使用大響應的測試時間
這些結果（除了 Axis2）是與您根據正在進行的安全性處理得到的預期是一樣的。通過這兩種安全性配置，客戶端和服務之間的消息交換使用了對稱加密。這兩者最大的不同是 WS-Security 對稱加密配置使用了客戶端為每一個請求/響應消息對生成的一個新的保密密鑰。這個保密密鑰需要使用服務器的公鑰進行不對稱加密，然後它會作為請求消息的一部分發送，這樣 WS-SecureConversation 就可以在許多消息對中重用一個保密密鑰。這意味著 WS-Security 配置為每個請求帶來嚴重的過載，這主要顯示在 圖 1 的時間中。
這些工具並不支持使用 WS-Security 對稱加密來只 加密一條消息，而是同時還要求使用簽名才能完成。這使得我們很難作直接的性能比較，但是您可以通過將這些圖表與 “WS-SecureConversation 性能” 中的圖表進行比較來了解它們之間的區別。前一篇文章顯示 WS-SecureConversation 對稱加密顯然比 WS-Security 不對稱加密具有更好的性能，特別是在加密消息時。這些結果表明使用客戶端生成的密鑰進行 WS-Security 對稱加密幾乎和 WS-SecureConversation 一樣快，特別是對於較大的消息。
結束語
您已經從本文中了解了對稱加密是如何在不需要客戶端證書的情況下使用客戶端生成的保密密鑰來保證消息交換的安全。當消息相對較大時，這個方法在實現消息交換時有很好的性能 — 幾乎與 WS-SecureConversation 一樣好。如果只有少量的消息在客戶端和服務器之間交換，客戶端生成的保密密鑰可以實現 WS-SecureConversation 保密密鑰更好的性能（因為 WS-SecureConversation 要求在客戶端和 STS 之間使用額外的消息交換）。
客戶端生成的保密密鑰也可用於消息簽名。雖然本文沒有介紹，但是保密密鑰的使用方法本質上與 “WS-SecureConversation 性能” 中討論的 WS-SecureConversation 簽名例子是一樣的。使用保密密鑰進行簽名本身比使用私有密鑰進行簽名的真實性保證較弱一些，但是它對於保證消息在傳輸中不會被篡改還是很有用的。
本系列的上幾篇文章討論了在 Web Services 中使用的幾種形式的 WS-Security 和 WS-SecureConversation 安全性技術，包括三種主流 Java Web Services 工具的性能比較。我將在將來的文章中介紹具體的 WS-Security 特性，但是現在是時候對安全性性能進行總結了。本系列的下一篇文章將總結這三種主流 Java Web Services 工具的性能和互操作性問題，同時提供在這些工具中使用 Web Services 安全性的最佳使用方法的指南。如果您想要在您的組織中使用安全的 Web Services，您一定不希望錯過這篇文章。
下載
