0 引言
目前多數實際應用系統的安全功能模塊都采用內嵌業務模塊的方式開發實現，安全組件和業務組件耦合度過高，導致兩者之間的交互關系繁雜，功能邏輯抽離性差；另外，安全系統涉及認證、授權、訪問控制和責任認定等領域，現有的集中開發模式沒有從軟件形態、邏輯形態以及最后的物理形態上對安全組件進行進一步構件化分離，造成部件功能劃分模糊重疊，不易開展安全功能專有評測，二次開發代價高、周期長、風險大。
1 相關工作發展現狀
網絡應用的高速發展和分布式服務的不斷深入使得系統安全產品從封閉型、單體化的形態向協作型、可插拔的中間件模式轉變。近年來，國際上已涌現出一批具有影響力的安全中間件項目。耶魯大學開發的CAS，Internet2/Mace和IBM開發的Shibboleth，英國Kent大學開發的PERMS，美國NASA開發的Cardea等都采用了面向專有安全功能開發的中間件形式。提供針對單一需求的安全服務。但是這些中間件系統內部構件化和可替換性還處在粗粒度的發展階段，封裝的算法和協議層次單一，無法適應企業應用對安全功能定制的裁剪性和敏捷性需求�；旧蠜]有提供面向安全開發人員或者業務涉及人員進行多次開發、自由組裝的平臺和方法。
還有一些旨在提供基礎性安全技術的開發包，例如Bouncy Castle Crypto、Crypto++、IAIK Crypto等，這些項目可以提供全面豐富的密碼算法具體實現、公鑰/屬性證書生成器、密碼學相關數學工具。已經在很多實際系統作為安全基礎設施大量應用，但其兩個基本不足在于：開發包內部結構仍然比較復雜，即使面向專業人員的學習曲線仍然較高；缺乏構建上層安全集成服務的組裝模式和開發模版，不能提供直接面向業務安全的功能接口，后期的開發量仍然較大。
2 基于共性安全構件的安全業務建模
本文提出的共性安全構件，又稱為信息安全共性構件，旨在將安全功能從傳統的業務邏輯中分離，進而分割成具有不同安全子功能的模塊，各模塊對外提供接口，獲得可獨立開發，可方便組裝、拆解、更換的優勢。共性安全構件提供良好的擴展性，可以用于快速便捷地搭建安全系統，從而實現安全系統自底向上的，配置型可定制性開發。
2.1 共性安全構件三層結構
共性安全構件可以按其實現完整功能的復雜度劃分到三個不同層次的子集中。基礎構件只實現一個具體算法或者定義具體的算法結構，處于最底層；功能構件由基礎構件搭建而成，能獨立提供一種安全業務功能；服務構件由基礎構件和功能構件搭建而成，實現一套完整的安全業務，并能以web服務的形式供外部調用。
2.2 基于服務構件的安全業務建模方法
共性安全構件的開發是從底層基礎構件到中層功能設施構件然后到上層的集成服務構件，而業務流程的開發是從上層業務建模到中層的過程分析然后到底層的服務集成，這是兩個不同方向的開發。
現有系統的安全功能開發往往局限于具體的安全事務，缺乏從安全業務的角度考慮流程安全完整性。本文從已有的應用業務中抽取并設計了一個完整的安全訪問業務流程，利用BPEL編排將構件開發與業務流程開發無縫地結合起來，形成完善的安全業務流程的開發模式。
BPEL是為整合web服務而制定的一種標準規范，它可以在不影響原有web服務正常運行的前提下，將web服務進行調度和協調，從而形成具有商業價值的業務流程。在基于服務構件的安全業務流程開發過程中引入BPEL語言，可有效提高安全系統開發的效率。
安全訪問業務流程主要包括安全認證，授權與訪問控制，審計與責任認定三大處理流程。在這些處理流程之下，還集成了域定位服務、認證服務、跨域身份聯合服務、斷言服務、策略查詢服務、屬性查詢服務、審計記錄服務等跨域或單域訪問過程中需要的web服務，能夠提供一套完整的安全訪問業務流程所需的各種功能。以下通過訪問控制流程的實施步驟和其中涉及的子流程給出完整的實現步驟說明。
訪問控制流程是從業務的角度利用BPEL建模工具對服務構件進行粘合從而實現靈活的安全訪問控制系統。整個流程包含了一個總的訪問控制過程，包括認證，授權以及審計部分。每一個功能的具體實現都封裝在所調用的服務構件中。流程中不包括細粒度的安全處理過程。
BPEL流程的執行過程描述采用了程序設計語言偽代碼的方式，其中變量和方法的命名都采用了統一的形式，目的是使流程的執行過程表述更加清晰，是實際BPEL流程建模和執行過程的抽象描述。
BPEL流程中調用的每一個web服務可以是由web服務粘合而成的子流程，例如對訪問控制流程中的Authentication Enforce Service，可以采用BPEL流程進行建模，如圖1所示。
圖1 BPEL建模的安全認證過程流程圖
這樣，我們利用BPEL自上而下地從業務流程的角度構建了一個安全訪問控制系統模型。通過這種方式，可以從很大程度上避免對底層細節的處理，這些細節可以交給具體的web service以構件的形式進行封裝。由于不涉及到細節處理。可以使流程的執行邏輯更加嚴密，從更大程度上減少系統的安全漏洞和隱患。同時由于web service可以根據需要而更換，系統的升級和更新將更加方便，減少了系統維護的代價。
2.3 共性安全構件組裝開發技術
AOP和DI技術是軟件工程領域成熟的開發方法。它們面向接口和對象，采用程序設計語言提供的反射機制實現系統的動態部署和功能替換。
本文從構件的層面，將AOP和DI思想引入到共性安全構件的組裝開發過程中，將提供類似功能的構件歸類，抽取通用的操作接口。上層構件對底層構件的調用采用松散耦合機制，對易變的底層構件調用其接口，具體構件在部署時由配置文件指定，這樣可以有效提高構件的復用性，同時加快構件部署系統時的效率和靈活性。下面結合屬性檢索構件說明如何將AOP和DI的思想結合到共性安全構件的開發過程中及其帶來的優勢。
在傳統的訪問控制模型中，屬性檢索必不可少。通常需要根據用戶的屬性信息來為其提供相應的訪問權限。但是在不同的應用場景下，不同的對象屬性檢索方式可能不同。如果在設計一個訪問控制系統的時候，使用哪種屬性檢索方式還不確定，通常的做法將會是將所有的屬性檢索構件全部集成到其中，然后根據用戶提供的消息來決定使用哪一個構件，正如圖2中所描述。這與設計安全構件的初衷相背離。用安全構件搭建系統的優勢就是構件可方便進行拆解和組裝，易更換和升級。
圖2 集成式屬性檢索構件
下面結合AOP和DI思想，提供一種更好的解決方案。圖3顯示了重新設計的屬性檢索構件架構，首先提取出所有屬性檢索過程所需要的操作，然后將這些操作封裝成一個接口Attribute Retrieve Faetory。每個屬性檢索構件都實現該接口，遵循該接口定義的規范。系統開發時針對接口進行編碼，運行時根據配置文件，采用面向對象語言的反射機制注入實際需要的具體屬性檢索構件。每一個屬性檢索構件只要實現了該接口，就可方便地組裝到系統中。這樣既可簡化系統架構，又有利于系統的擴展，方便新的屬性檢索構件的開發和配置。
圖3 采用AOP和DI思想實現的遁用屬性檢索構件
在創建構件的過程中，合理地使用AOP和DI思想可以帶來很大的方便。雖然采用反射機制在運行時創建對象會帶來一定的效率損失，但是可以簡化系統架構，優化配置過程，更重要的是使系統的擴展、構件的開發應用更加方便快捷。反射機制和對象的動態生成功能在靜態面向對象語言如Java、C#中都已經提供了一定的機制來實現，可以較方便地將其應用到構件開發應用中。依賴注入結合AOP思想的開發技術，可以將構件之間的繼承關系和共性特征很好地展現出來，使構件層次劃分、類別劃分更加清晰，也更容易實現構件的開發、組裝、擴展和升級。圖4描述了基于AOP和DI思想的安全構件組裝開發模式。
圖4 基于AOP和DI思想的安全構件組裝開發模式
3 性能測試與實驗數據
本節從系統性能方面，針對之前設計的安全業務流程中安全認證系統進行測試，獲取試驗數據并與傳統的安全認證中間件產品CAS、OpenID協議進行比較，驗證安全構件集成建模方法的有效性。為了使系統之間更具可比性，本文只針對服務端一次成功驗證的時間進行比較，時間的截取從認證信息發出到認證斷言頒發成功為止，采用統一的用戶名口令認證方式。同時為了減少網絡IO對傳輸速率的影響，認證系統都采用本地部署的方式，并且CAS和OpenID協議都采用單域的認證機制，以減少跨域流程帶來的性能損失，防止其對比較結果產生影響。安全認證系統的BPEL流程圖如圖6所示，它包含了可用的四種具體認證方式。本節只對用戶名口令認證方式進行測試。其他三種方式的認證服務構件并未實現。但是為了使比較結果更加趨于實際應用，流程中保留了分支活動。為此，安全認證BPEL流程接受的輸入參數除了包含用戶名、口令之外，還有所選擇的認證方式標識，如圖5所示。
圖5 安全認證系統輸入參數
CAS和OpenID的基本認證流程如圖6所示，本試驗為減少實驗環境對測試性能的影響，將客戶端、依賴方、認證服務器部署到統一機器上，并且只統計認證服務器進行認證的時間，即圖6流程中從客戶端發送用戶身份數據(步驟3)到依賴方收到認證結果(步驟4)之間的時間。
圖6 CAS和OpenID的基本認證流程
本文利用3GHz主頻、2G內存的計算機，部署了CAS 3.0服務、OpenID服務以及安全認證系統，采用本地MySql身份數據庫，針對一次成功的單域認證所用的時間，對三個系統性能進行比較分析，另外還對安全認證系統內的用戶名口令認證服務構件做了測試，以此分析基于BPEL構件整合方案的性能損耗。具體數據見表1所示。
表1 各認證系統性能數據比較
通過上述數據可以看出，基于安全服務構件搭建的安全認證系統在效率上較CAS和OpenID更為出色，但是與直接使用口令認證服務構件進行認證的效率相比，卻存在一定差距。根據認證流程可以分析得出，這部分效率損失主要集中在web Service接口調用時，對數據的xml編解碼過程之中。由此可見，使用BPEL粘合服務構件搭建安全業務系統，是以部分性能損耗為代價，換取高效的開發、靈活的部署方式，在很多場景下是具有實際應用價值的。
為了提高安全業務系統的效率，可以增加安全服務構件的粒度，減少安全業務流程中web service的調用次數；此外，研發更加高效的安全服務構件粘合技術是解決該問題最直接的手段。
4 結語
本文試圖介紹一種新型的建模方法，通過將AOP和BPEL等軟件開發技術和思想結合到信息安全共性構件的開發和應用中，使信息安全系統的建模過程更加方便，從上層而言避開了瑣碎的實現技術細節，所建立的系統邏輯清晰，從而減少了系統中存在的安全漏洞，具有更高的安全性能。同時從底層而言由于信息安全共性構件的使用，系統的可重用性大大提高，用戶可以根據實際需要更換相應的構件，具有良好的擴展性，系統的維護和更新更加便捷。
從長遠來看，云計算、服務托管是近來新興的業務模式和網絡應用層體系結構。由此產生出新的安全需求和安全問題。包括策略集成在內的諸多安全技術應更好地借助共性安全構件這一先進開發理念，從新的業務角度出發，重新定位受保護的核心資產和安全目標實施方式．提供與產業應用升級同步的安全服務模式升級。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：基于服務構件集成的安全訪問業務建模方法
相關文章
