Java Web Services 安全實戰：無需客戶端憑證的 WS-Security 對稱加密方案

傳統 WS-Security 依賴雙向 X.509 憑證 (非對稱加密)，雖提供強身份驗證，但帶來效能開銷與憑證管理負擔。本文介紹基於 客戶端產生對稱金鑰 的 WS-Security/WS-SecureConversation 方案，僅需伺服器憑證即可實現訊息加密簽名，大幅簡化部署並提升效能。

核心原理：客戶端產生對稱金鑰

1. 客戶端產生隨機對稱金鑰 (或衍生金鑰)
2. 使用伺服器公開金鑰 (X.509 憑證) 非對稱加密該金鑰
3. 將加密金鑰嵌入 <xenc:EncryptedKey> 標記置於請求訊息中
4. 雙方使用該對稱金鑰 (或衍生金鑰) 加密/簽名 SOAP Body
5. 伺服器以私鑰解密取得對稱金鑰，無需回傳金鑰

此機制隱含於 <sp:SymmetricBinding> 搭配 <sp:X509Token sp:IncludeToken="Never"> 的政策斷言中。

WS-Policy 配置詳解

純 WS-Security 對稱加密 (清單 1)

<sp:SymmetricBinding>
  <sp:ProtectionToken>
    <sp:X509Token sp:IncludeToken="Never">  <!-- 僅用於保護金鑰傳輸 -->
      <sp:RequireDerivedKeys/>
      <sp:RequireThumbprintReference/>
      <sp:WssX509V3Token10/>
    </sp:X509Token>
  </sp:ProtectionToken>
  <sp:AlgorithmSuite><sp:Basic128Rsa15/></sp:AlgorithmSuite>
  <sp:Layout><sp:Strict/></sp:Layout>
</sp:SymmetricBinding>
<sp:EncryptedParts><sp:Body/></sp:EncryptedParts>

關鍵點：IncludeToken="Never" 表示憑證不隨訊息傳輸，僅以指紋 (Thumbprint) 參考；RequireDerivedKeys 強制衍生金鑰增強安全。

WS-SecureConversation 無客戶端憑證版 (清單 2)

將 BootstrapPolicy 內的 <sp:AsymmetricBinding> 替換為上述 <sp:SymmetricBinding>，實現 STS 握手階段同樣無需客戶端憑證。完整政策巢狀結構見原文清單 2。

三大主流框架互操作性測試

Axis2 對稱加密實現存在嚴重效能缺陷 (疑為金鑰處理線性查找)，且無法通過對稱 Bootstrap 的 WS-SecureConversation 測試。

效能基準測試

測試環境

• 地震資料查詢服務 (93,000+ 筆資料)
• 兩類負載：小回應 (1,000 請求/816 結果) 、大回應 (100 請求/176,745 結果)
• Tomcat 6.0.20, Sun JDK 1.6.0_10, 32-bit Linux

結果分析

• 小回應：Metro 最快，比 CXF 快 ~10%，比 WS-Security 對稱加密快 ~30%。WS-Security 對稱加密每請求需非對稱加密金鑰，開銷顯著。
• 大回應：Metro 與 CXF 差距僅 ~10%，對稱加密優勢明顯 (加密主導開銷)。WS-SecureConversation 重用金鑰，大訊息下接近對稱加密效能。
• Axis2 缺席：小回應測試中 Axis2 耗時超過 Metro 40 倍，排除於圖表。

關鍵結論

1. 無客戶端憑證可行：客戶端產生對稱金鑰 + 伺服器憑證保護金鑰傳輸，完全滿足加密/簽名需求。
2. 效能優異：大訊息下接近 WS-SecureConversation；小訊息/低頻交換優於 WS-SecureConversation (省去 STS 握手)。
3. 框架支援不均：CXF 支援最完整；Metro 需額外 WS-Addressing；Axis2 存在嚴重缺陷，生產環境謹慎評估。
4. 簽名同樣適用：對稱金鑰可用於 HMAC 簽名，雖非否認性較弱，但足夠保證傳輸完整性。

部署參數

• 客戶端：需信任存儲 (含伺服器憑證)
• 伺服器：需金鑰存儲 (含私鑰)
• 參數傳遞採實現無關方式 (參考系列文檔)

下一篇將總結三大框架安全效能與互操作性最佳實踐指南，敬請期待。