企業應用Web服務安全：問題介紹(圖)

　　介紹為何需要Web服務安全
　　
　　本文關於如何在企業環境中實現和應用基於Web服務安全技術(WSSecurity)的安全防護方案這一系列文章的第一篇使用訪問控制機制來保護公司的Web服務資源的安全是企業應用的典型特征之一此特征同其它特征一起組建企業應用環境此系列中將要提出的針對開發安全防護方案的建議和設計多數來源於筆者在實現TransactionMinder一個先進的Web服務安全保護系統中獲得的第一線開發經驗以及客戶的需求筆者在此處特意作了一般化處理使得這些思想和設計可以應用在其他可比較的安全保護系統中
　　
　　本系列文章沒有討論到的問題
　　
　　首先WSSecurity理論基礎的方方面面以及如何使用WSSecurity來保護SOAP Web服務的資料隨處可見因此關於WSSecurityXML安全XML加密XML簽名SAML(Security Assertion Markup Language: 安全聲明標記語言)PKI(Public Key Infrastructure: 公鑰基礎設施)等技術的理論基礎及一般討論請參考相關出版物以及在線資源請參考下面的資源部分
　　
　　當然對於涉及到的技術以及在討論組件實現的相關章節中提到的不同組件的目的會給出解釋不過筆者假設讀者對這些主題有最低程度的基本理解
　　
　　其次許多討論如下主題的文章已經發表:
　　
　　●Web服務在業務流程自動化以及異構系統互聯等領域的良好前景
　　
　　●在上述領域中應用Web服務的障礙首先並且最主要的是Web服務安全保護機制的(或者是覺察到的)缺乏
　　
　　此處沒有必要重復為安全通信提供標准和工具的重要性也沒有必要重復令人費解的安全標准制定過程以及標准發展的復雜性
　　
　　從Internet商業化的開始階段起就存在對於構建標准BB自動處理鏈技術的不斷嘗試(某些做的確實不錯)在此處理鏈中每個Web服務參與節點需要依次扮演服務器和客戶(當它向處理鏈中的下一個節點請求服務時)的角色從安全的觀點看一個節點需要向下一個節點提交自己的信用標記或者抽取並向下一個節點傳遞信用標記以聲明自己信任此信用標記在SAML的術語中這兩種方法分別被稱為密鑰擁有者(HolderofKey HK)以及發送方擔保(SenderVouches SV)它們被用來聲明加密信息所使用的加密運算的私鑰的擁有者(請參考 安全聲明標記語言 綁定和概要 PDF文檔的第節)圖中Web服務節點AB之間通信使用密鑰擁有者(HK)方法節點BC之間通信使用發送方擔保(SenderVouches SV)方法
　　　
　　圖 密鑰擁有者 請求(HolderofKey HK)以及發送方擔保(SenderVouches(SV)請求
　　
　　標記解釋　A auto token A的驗證標記; A public key A 的公鑰; A signature A的簽名; B public key B 的公鑰; B signature B的簽名
　　
　　從理論轉回來考慮當前企業軟件環境首先需要注意的是作為Web服務保護機制的訪問控制系統(如Digital Evolution的TransactionMinder 或 Management Point　)的存在這些保護機制普遍用於保護系統防御輸入的SOAP消息中潛伏的攻擊因此比傳統的防火牆復雜得多它們除提供標准防火牆功能外還提供對於WSSecurity以及相關技術的支持
　　
　　因此為支持實現上述的自動服務鏈作為請求方的Web服務節點應該對輸出的信息進行適當處理使其可以被保護目的Web服務節點的訪問控制系統所接受
　　
　　在本系列文章的主要關注點是對於位於不同的訪問控制系統後的Web服務節點互聯問題提供(膠水)方案這需要實現傳統的WSSecurity的功能的子集但是又略微不同實現細節會在下面的需求部分討論一個示例(工具包)實現會在後續的文章中展開
　　
　　鏈條的缺失部分問題
　　
　　顯然企業級的訪問控制系統不會孤立存在它們同後台的用戶目錄服務器和訪問策略服務器連接這些服務器可以提供用戶信用標記以及基於訪問策略做出訪問控制決定
　　
　　典型的訪問控制系統需要處理驗證和授權任務基於不同的配置方案系統可以接受許多種類的信用標記對於Web服務訪問控制系統除其他需求外特別地需要支持不同的基於Web服務安全的方案系統需要從輸入的Web服務信息頭部的WSSecurity信息部分提取並使用用戶信用標記來驗證請求者另外如圖所示訪問控制系統還需要能夠修改輸入的請求信息如添加額外的安全頭部信息添加特定的驗證標記和簽名以及進行消息解密等
　　　
　　圖 訪問控制系統的角色
　　
　　標記注釋 Validation 確認 Authentication 驗證Authorization 授權 policy store 策略庫User Directory用戶目錄對Web服務輸出信息自動地進行安全處理以及對輸入請求的狀態信息和信用標記自動的進行提取現有的訪問控制系統還無法做到實現這樣功能可能需要一個特殊的復雜代理或者網關在輸出信息輸出前對其進行修改處理當前這方面的工作多數集中在硬件方面(比如DataPower的 XS XML Security Gateway)軟件實現雖然提供了豐富的類似硬件代理的功能但是實際上很有限
　　
　　因此企業Web服務的開發者不得不手工編寫代碼來提取信用標記並對輸出信息進行適當的安全處理這需要對XML進行手工解析 或者利用常見的XML簽名加密(Apache XML Security 項目IBM XML Security Suite)SAML(SourceID SAML 工具包 )或者WSSecurity(Apache的 WSSJ 項目 Phaos WSSE Toolkit)等工具包
　　
　　由於WSSecurity涉及相當廣泛的技術因此其實現必然依賴於許多外部的軟件開發包現在可用的軟件開發包不少不過彼此之間存在的兼容性很差利用所有的工具包使其兼容本身就是一個大挑戰不兼容的問題舉例如下支持的算法集合不同不兼容的證書格式使用的JDK版本的沖突依賴的XML解析器的不兼容性
　　
　　WSSecurity標准本身具有通用性功能豐富實現完整支持標准的通用WSSecurity SDK 將導致異常復雜的API進而組織內開發者基於特定需求需要對此API簡化包裝時通常需要付出額外的開發工作
　　
　　最後不得不提到的是現有的安全SDK通常是自依賴的——其功能等依賴於自己提供的信用標記存儲結構及其訪問接口對於企業現有的策略以及用戶目錄服務器等並未提供良好的掛鉤(hook)企業開發者需要利用已有的存儲設備等基礎設施實現新的系統需要與已有設備連接因此通常需要在系統中整合多種類型的信用標記存儲方案和標記格式這意味著需要為兼容性進行多層次的封裝工作
　　
　　目的解決方案的需求
　　
　　這裡考慮特別的案例——作為在已有訪問控制系統下開發企業Web服務的開發者我們並不需要一個完全支持標准的膨脹的SDK相反在此環境下為保護自動化處理鏈的安全需要一個相對輕量簡單的API來幫助解決現存的方案的不足
　　
　　在請求信息到達目的Web服務節點前目的節點前端的訪問控制系統需要對請求信息進行特定的安全處理特別的處理包括首先進行的消息驗證(消息結構和完整性)以及簽名驗證和對任何加密內容的解密等在我們的實現中Web服務的請求輸入點上應該是(可能)附帶已經驗證的WSSecurity頭部信息的有效SOAP信息以及頭部附加的特定驗證標記在圖中Web服務節點B處工具包應該協助開發者從(請求A的)輸入中提取驗證標記構造新的(位於請求B中的)WebSecurity標記或為了滿足目標系統(Web服務節點C)的策略需求而改變已有(請求A中包含的)信用標記
　　
　　圖 Web服務鏈
　　
　　開發的WSSecurity工具包應該滿足的更確切需求如下
　　
　　●現有的訪問控制系統已經使用了種類廣泛的後台策略及用戶信息服務器為任何工業級別應用而開發的安全工具包的一個必須特性是能夠與已有的基礎設施集成雖然要求工具包支持所有不同來源不同形式的基礎設施是不現實的但是它必須提供簡單通用的適配接口這些接口允許(通過配置)在現有工具包中添加為特定存儲提供者開發的插件來添加相應功能
　　
　　●通過第方SDK提供對於XML簽名XML加密功能的支持前面已經提到現在有一些相應的實現很可惜它們的相互兼容性很差同時為避免嚴重依賴於特定的SDK提供者和(或)其特定版本 工具包必須開放適當的掛鉤以便插入其它不同實現的包裝器 這些開放掛鉤的接口應位於SDK結構層次的底層如此保有對其他SDK的供應者的最廣泛的兼容性很幸運上面提到在本案例所需的密碼運算功能有限不需要進行簽名驗證解密以及其他一些標准密碼運算等功能
　　
　　●通過掛接點使用第方SAML SDK提供的SAML標記生成功能將實現的工具包僅關心如何正確地在消息頭部添加已生成的SAML標記(參考安全聲明標記語言　標記概要 PDF文檔 )
　　
　　●Web服務技術本身的異構特性決定工具包不能依賴於特定的平台如果需要平台相關的特性可以通過調用工具包公開API中的平台封裝層來添加
　　
　　●為降低開發工作量選擇工具包支持的安全標記的類型時 有必要做出的一定的限制同時工具包的設計要合理當需要添加並支持新的安全標記類型時工作不會太復雜以致無法完成也就是說工具包的設計過程應當盡可能的抽象同時注意擴展性
　　
　　●最後前面曾提到工具包應該保持相對輕量具有簡單的供外部調用的API同時應該以解決當前的特定問題為導向而開發這樣可以避免開發者學習使用另一個復雜API的負擔
　　
　　對於企業Web服務當前的訪問控
From:http://tw.wingwit.com/Article/program/Java/gj/201311/27423.html