背景：WS-Security 效能痛點
WS-Security 使用非對稱加密 (簽名/加密) 保護 SOAP 訊息，但每次請求/回應都需執行昂貴的 RSA 運算，導致高併發下 CPU 瓶頸。WS-SecureConversation 引入 安全上下文 (Security Context Token, SCT)：客戶端先與 STS (Security Token Service) 以非對稱加密交換金鑰材料，建立共享對稱金鑰；後續訊息交換改用對稱加密 (AES/3DES)，大幅降低運算成本。
三大棧 WS-SecureConversation 設定差異
共同策略結構
- BootstrapPolicy：STS 交換階段，非對稱綁定 (X.509 Token)。
- SymmetricBinding：應用階段，對稱綁定 (SCT)，衍生金鑰。
Axis2 / Rampart
- 客戶端：
RampartConfig 在 Policy 中指定 keystore、callback handler。
- 服務端：
services.xml 需額外載入 rahas (STS) 模組、addressing 模組。
- STS 設定：
sct-issuer-config 參數指定金鑰衍生機制 (keyComputation=3 使用自有金鑰)。
- 啟用 WS-Addressing：
client.engageModule("addressing")。
CXF
- 設定最簡單：
cxf.xml 以 .sct 後綴區分 STS 階段參數 (signature/encryption properties、username、callback handler)。
- 服務端：
web.xml 載入 cxf-extension-addr.xml 啟用 WS-Addressing；cxf-servlet.xml 定義 endpoint 與 SCT 參數。
- 無需額外 STS 模組設定，開箱即用。
Metro (WSIT)
- 參數直接內嵌 WSDL Policy：
wssc:KeyStore/wssc:TrustStore (客戶端)，wsss:KeyStore/wsss:TrustStore (服務端)。
- STS 設定自動從 BootstrapPolicy 繼承，無額外配置。
- 整體設定量最少，最貼近標準 Policy 宣告。
效能測試環境
- 硬體：Athlon X2 5400+、4GB RAM、Mandriva 2009.1 64-bit
- JVM：Sun/Oracle Java 1.6.0_18 32-bit (大堆記憶體表現優於 64-bit)
- 容器：Tomcat 6.0.20 (Server Heap 1024MB, Client Heap 512MB)
- 棧版本：Axis2 1.5.1/Rampart 1.5、Metro 2.0、CXF 2.1.8
- 測試服務：地震資料查詢 (93,000 筆)
- 兩組負載：
① 1,000 請求、小回應 (816 筆匹配) → 考驗請求處理吞吐
② 100 請求、大回應 (176,745 筆匹配) → 考驗資料序列化/傳輸
測試結果關鍵發現
無安全基準
- Metro 2.0 處理小回應最快 (~25% 勝過 Axis2/CXF)；大回應三棧持平。
WS-SecureConversation 三種模式
| 棧 | Sign (小回應) | Encr (小回應) | SignEncr (小回應) | Sign (大回應) | Encr (大回應) | SignEncr (大回應) |
|---|
| Metro | 最快 | 最快 | 最快 | ≈CXF | ≈CXF | ≈CXF |
| CXF | 次之 | 次之 | 次之 | 最快 (~15% 勝 Metro) | 最快 | 最快 |
| Axis2 | 最慢 (~2x Metro) | 最慢 | 最慢 | 最慢 (~2x CXF) | 最慢 | 最慢 |
對稱 vs 非對稱加密效能增益
- 小回應 + 僅簽名：WS-SecureConversation 對稱加密比 WS-Security 非對稱快 2 倍以上 (三棧一致)。
- 大回應 + 簽名加密：對稱加密優勢明顯，但隨資料量增大，XML 規範化 (Canonicalization) 成本主導，增益縮小。
- 原因：簽名必須先 Canonicalization → Hash → 非對稱簽名；加密僅需對稱加密資料本體。對稱加密速度遠快於非對稱，但在大資料量下 Hash/Canonicalization 成為瓶頸，抵銷優勢。
架構選型建議
- 持續高頻呼叫 (如金融交易、即時饋送) → **WS-SecureConversation 必選**，效能提升顯著。
- 一次性/低頻呼叫** → 不建議啟用，STS 交換額外 RTT 反而增加延遲。
- 棧選擇：
• 效能優先 + 簡單設定 → **CXF** (大回應最佳、設定簡潔)。
• 標準相容性 + 小訊息高吞吐 → **Metro**。
• 既有 Axis2 投資 → 需接受效能折扣，或規劃遷移。
- 記憶體注意：Axis2 SignEncr 客戶端需 ~800MB Heap，CXF 僅 ~48MB，容器密度差異巨大。
互通性提醒
WS-SecureConversation 互通性較 WS-Security 復雜 (SCT 格式、衍生演算法、WS-Addressing 版本)。跨棧整合前務必執行互通性測試 (WS-I Basic Security Profile)。
結語
WS-SecureConversation 以對稱加密取代重複非對稱運算，為持續性 Web Service 呼叫帶來 2x~10x 效能飛躍。CXF 在大訊息、Metro 在小訊息上各有優勢，Axis2 則在記憶體與 CPU 雙重劣勢。根據呼叫模式與訊息大小選擇棧與安全策略，是高效能 SOA 的關鍵。
