大規(guī)模信息系統(tǒng)應用中的用戶集成策略與實現

陳 煒，柯水洲，李 強

（1.河北農業(yè)大學人事處，河北保定 071001；2.國防科技大學軍事職業(yè)教育技術服務中心，湖南長沙 410000；3.中國軟件與技術服務股份有限公司，北京 100081）

0 引言

大型企事業(yè)單位的信息化建設往往需要大規(guī)模地組織運用各類應用系統(tǒng)，在此過程中，既要開發(fā)新的業(yè)務系統(tǒng)和功能模塊，又要對現存系統(tǒng)進行集成再造。Jinyoul等［1］指出基于組件的開發(fā)能促進企業(yè)集成。目前成熟的做法是通過實現應用支撐平臺來完成整個信息生態(tài)的體系建設與系統(tǒng)集成［2-3］。應用支撐平臺又可劃分為基礎支撐應用、系統(tǒng)集成應用、信息協(xié)同應用等，其中系統(tǒng)集成應用是實現信息全面集成的關鍵模塊。系統(tǒng)集成應用需要從用戶集成、界面集成、消息集成、數據集成、服務集成、工具集成等多個環(huán)節(jié)打通信息壁壘，其中用戶集成是最為關鍵與首要的任務。

藏靜［4］以用戶數據集成為例闡述企業(yè)信息系統(tǒng)集成方法時，將人力資源數據庫和業(yè)務系統(tǒng)用戶同步到統(tǒng)一的用戶庫，通過保存業(yè)務系統(tǒng)用戶的每一次信息變更進行用戶數據同步，但存在較大的系統(tǒng)開銷；楊金文［5］在討論單點登錄系統(tǒng)時，將統(tǒng)一的用戶管理、統(tǒng)一的授權管理、統(tǒng)一的身份認證視為理想模型和解決方案，在小規(guī)模系統(tǒng)集成中效果較好，但在大規(guī)模異構系統(tǒng)集成中，特別是存在大量商業(yè)閉源業(yè)務系統(tǒng)的集成環(huán)境中，難以實現權限管理的完全一致和統(tǒng)一；徐步峰［6］基于Kerberos 實現認證模型，但為了避免單點故障、提高系統(tǒng)可用性，采用了冗余架構；雷傳銳［7］針對CAS（Central Authentication Service，中心認證服務）認證方式，提出采用帶權重的粗粒度、IP 禁止功能及登錄次數閾值等模型和方法，提升了用戶認證的安全性；祝慶績［8］、張潔等［9］闡述了基于CAS 的認證中心實現方案；鄭?。?0］、陳國慧等［11］分別使用CAS 技術實現了校園認證中心和門戶認證中心，但以上均把討論重點放在CAS 技術本身，主要闡述了CAS 基本概念、交互認證原理和配置部署方法，而忽略了對大規(guī)模異構系統(tǒng)用戶集成的實現邏輯分析與集成策略研究。

現有工作大多以實現單點登錄為目標，局限于小規(guī)模應用場景的技術實現，而沒有考慮到大規(guī)模異構系統(tǒng)集成環(huán)境下的系統(tǒng)開銷大、權限管理難等問題，缺乏系統(tǒng)的集成邏輯分析與策略研究，也沒有結合集成策略深入闡述CAS 的核心思想和框架使用邏輯。因此，本文從系統(tǒng)集成模塊實現的角度，總結了用戶集成的邏輯問題，分析了容易出現單點故障和用戶權限錯配的具體場景，提出改進策略和實現方法，并通過Apereo CAS 與Apache SHIRO 開源框架快速實現身份認證的集中式管理和角色權限的分布式管理策略。輕量級的原型系統(tǒng)驗證了解決方案的可行性，該方案不僅適用于從零開始構建信息系統(tǒng)的用戶集成模塊，而且適用于對現有信息生態(tài)進行升級、改造、集成與調優(yōu)。

1 用戶集成邏輯問題與策略研究

企事業(yè)單位在大規(guī)模組織運用信息系統(tǒng)時，常常會遇到大規(guī)模用戶集成的問題。為有效解決系統(tǒng)開銷大、權限管理復雜等難題，消除單點沖突和權限錯配，應首先分析相關邏輯問題，以便給出相應策略和實現方法。

1.1 符號約定

把內部信息生態(tài)中的所有應用記為集合M=｛A1，A2，…，An｝，其中An表示一個具體應用。把集合M 中的應用劃分為若干個域，所有域的集合記為N=｛D1，D2，…，Dn｝。集合N 中的域一般分為3 種類型。不失一般性，把基于相同應用支撐平臺和技術體系，使用相同機構用戶及權限管理數據庫，重構、在建及將建的應用劃分到D1（如黨建管理、外事管理等系統(tǒng)），即為第一類；把購買的某個商業(yè)套件下的應用劃分到D2（如用友財務、人力、客戶關系等應用），即為第二類；把某個獨立的應用劃分到D3（如開源郵件系統(tǒng)），即為第三類。以下所有策略都將以D1、D2、D3為具體實例進行說明。

1.2 用戶數據存儲域及用戶管理實現域

將新建或大量重構的系統(tǒng)劃分到D1，原則上使用相同的綜合管理數據庫和應用支撐平臺進行用戶集中存儲與權限管理。對于域D2和D3，各自進行獨立的用戶數據存儲與用戶權限管理［5］。

1.3 域之間用戶訪問控制與認證授權問題

假設用戶U 既是D1中的用戶，又是D2中的用戶，如果用戶U 已通過中心認證登錄了D1或D2中的任意一個應用Ak，則可直接訪問D1和D2中的其它應用，而無需再次認證。假設用戶U 是D1中的用戶，而不是D2中的用戶，其通過認證中心登錄了D1中的應用An，此時要訪問D2中的應用Am。Am檢測到用戶U 已通過認證并從認證中心獲取到了用戶信息，但Am通過查詢本地獨立的用戶數據，發(fā)現用戶U 不是本地用戶，則跳轉到Am應用的本地認證入口，提示用戶進行認證。

1.4 不同域用戶進行綁定與映射的身份標識

首先分析通過用戶名作為標識進行映射會產生的邏輯錯誤。假設用戶U 通過認證中心登錄了D1中的應用An，正要訪問D2中的應用Am。Am檢測到用戶U 已通過認證，并從認證中心獲取了用戶名name1，此時可能出現3 種邏輯錯誤：

（1）如果用戶U 是D2的用戶，但在D2中的用戶名為name2，將造成用戶U 無法正常訪問Am。

（2）如果用戶U 不是D2的用戶，但恰好用戶V 以name1在D2中注冊過，將造成用戶U 可非法獲取用戶V 在Am中的權限，從而訪問到用戶V 在Am中的操作視圖，導致登錄故障。

（3）如果用戶U 在Am中的用戶名為name2，用戶V 在Am中的用戶名為name1，此時表面上實現了認證授權，但會造成用戶U 無法訪問自己在Am中的操作視圖，卻可非法訪問用戶V 在Am中的操作視圖，導致用戶操作權限錯配。

綜上，應采用如下集成策略：創(chuàng)建新的中心認證數據庫，用戶以唯一標識（如電子郵箱地址）作為認證中心的身份標識，并用該標識作為中心認證數據庫中的用戶數據和各域用戶數據的映射字段。例如：用戶U 在D1中的用戶名為name1，在D2中的用戶名為name2，但在D1和D2中均留有唯一的name@163.com 電子郵箱地址，則通過綁定郵箱、用戶名映射的方式在D1與D2之間正確地識別用戶進行認證和授權，從而實現自由切換。

此外，之所以要創(chuàng)建新的認證中心數據庫，是因為如果認證中心要針對不同應用和數據源進行認證與交互，不僅會造成邏輯錯誤，而且會增加集成開發(fā)的工作量和復雜性，甚至降低系統(tǒng)性能。

1.5 用戶數據綁定與同步以及各域認證入口訪問控制

（1）用戶同步。各域的用戶范圍顯然是不同的，將中心認證數據庫同步到各域數據庫不符合邏輯，增加了大量無效且冗余的用戶數據拷貝。因此，解決策略是將各域中用戶數據的少量關鍵信息同步到中心認證數據庫。

（2）注冊同步。各域對用戶信息的內容要求不一，但至少要有中心認證數據庫所要求的用戶名、密碼、郵箱地址3 項內容。在各域中，如果有新用戶創(chuàng)建、身份標識（如電子郵箱地址）字段的增加或修改信息，則需要觸發(fā)事件，把用戶信息同步到中心認證數據庫。如果用戶U 是D1中的用戶，在通過認證中心驗證的前提下又在D2中注冊時，應從認證中心自動獲取D1中的身份標識作為注冊字段。

（3）用戶綁定。用戶U 把在各域中的身份標識（如電子郵箱地址）修改成自己常用的唯一身份標識，即實現了同一個人在各域不同賬號的綁定映射。

（4）認證入口。保留各域原有的登錄與認證入口，當用戶訪問受限資源時，首先跳轉到認證中心。如果未認證，則重新跳轉到認證中心登錄界面；如果認證中心已驗證通過，則進入各域內部。此時如果不是各域的有效用戶或不滿足該域的訪問權限，則跳轉到各域原有認證頁面或權限不滿足提示頁面。

不同應用間用戶數據存儲及交互策略如圖1所示。

Fig.1 User data storage and interaction strategies of different application圖1 不同應用間用戶數據存儲及交互策略

2 中心認證Apereo CAS實現

CAS 是用于實現Web 中心認證，使得單個用戶只提供一次憑證即可訪問多個應用的協(xié)議［7，12］。Apereo CAS 軟件由CAS服務器和CAS 客戶端［8，12］構成，可支持CAS、SAML、OpenID、OAuth 等多種協(xié)議［10，12］。

2.1 CAS協(xié)議核心思想及概念

CAS 的核心思想是應用程序的用戶登錄及身份認證交給CAS 服務器完成，用戶身份認證成功后，其相應角色和權限則可交給CAS 服務器進行二次開發(fā)集成，也可交給CAS 客戶端自己處理［12］。按照上文提出的集成策略，每個域為一個CAS 客戶端，各域的用戶操作權限交給各域處理，即身份認證的集中式管理和角色權限的分布式管理。CAS包括以下基本概念［7，12］：

（1）ST（Service Ticket）：代表訪問許可唯一不可偽造的服務標識碼，用戶認證通過后，ST 由CAS 服務器發(fā)出，通過Http GET 請求的URL 參數傳輸，且只對當前用戶有效。

（2）TGC（Ticket-Granting Cookie）：存放用于查詢登錄票據（憑證）TGT 的ID 信息的cookie，是CAS 服務器用來明確用戶身份的憑證，也是CAS 服務器與客戶端通信交換的載體，只能采用Https安全方式傳輸。

（3）TGT（Ticket Grangting Ticket）：存儲在TGC 中，代表用戶的一次會話，也是用戶證明自己在CAS 服務器登錄過的憑證。

2.2 CAS協(xié)議基本原理

當瀏覽器發(fā)出GET 請求要訪問應用An時，An（CAS 客戶端）攔截請求，把請求地址記錄下來暫存，重定向請求到CAS 服務器的登錄地址，并將An中CAS 客戶端程序的接口地址一并發(fā)給CAS服務器。

假設是首次訪問，則跳轉到認證中心登錄頁，此時用戶填寫身份信息（如用戶名）和憑證（如密碼）并提交。若認證成功，則生成TGT 緩存在CAS 服務器，將TGC（TGT 的ID 信息）寫入到客戶端瀏覽器，簽發(fā)ST，以ST 作為URL 參數重定向到CAS 客戶端的接口地址。CAS 客戶端收到攜帶ST 的請求后，將ST 轉到CAS 服務器進行驗證。ST 與TGT 若能匹配成功，則用戶通過身份驗證，CAS 服務器將用戶信息回傳給CAS 客戶端，由CAS 客戶端與用戶建立會話，返回受保護的信息資源，并以網頁形式呈現給用戶。

當瀏覽器訪問應用Am時，Am將請求跳轉到CAS 服務器，CAS 服務器檢查TGC（cookie），發(fā)現已經通過驗證，則簽發(fā)ST 發(fā)送給Am的CAS 客戶端。Am的客戶端收到攜帶ST 的請求后，轉交CAS 服務器進行驗證。驗證通過后，CAS 服務器將用戶信息回傳給Am的CAS 客戶端，由Am的CAS 客戶端與用戶建立會話，以網頁形式呈現被保護的信息資源給用戶。CAS 協(xié)議工作原理時序圖如圖2所示［11-13］。

2.3 CAS服務器搭建

（1）首先創(chuàng)建中心認證數據庫，并將域用戶數據同步至中心認證數據庫ca_db。其中，必有字段為uid、username、password、email。email 為CAS 服務器和CAS 客戶端用戶數據的映射字段，一個用戶可在多個應用中注冊賬號，同步到ca_db 后，則有了多條記錄。登錄名與密碼可以不同，如果已經綁定，郵箱地址相同，只要使用郵箱和任意已有賬號的密碼，均能通過CAS實現身份認證。

（2）在maven 中加入cas-server-support-jdbc-drivers 和mysql-connector-java 支持包，編譯一份CAS 服務器執(zhí)行程序，以便采用讀數據庫比對密碼的方式進行驗證［10-12］。

Fig.2 CAS protocol interaction sequence diagram圖2 CAS協(xié)議交互時序圖

（3）用JDK 生成密鑰庫、證書文件并導入到JDK，修改tomcat的server配置文件，把密鑰加入密鑰庫［9-10，12］。

（4）修改CAS 服務器配置，設置為JDBC 認證方式。CAS 可針對多個CAS 客戶端的加密方式設置多種常用的加密校驗方式，只要任意一種加密方式匹配成功即能通過驗證。更為復雜的情況則需進行二次開發(fā)，以下為CAS 的JDBC 認證配置方法［11-12］：

3 CAS客戶端的Apache SHIRO 實現

Apache SHIRO 可簡單、快速地實現用戶認證、加密、授權、會話、緩存及Web 集成等功能，用戶、角色及權限數據的維護由使用者自定義并擴展實現，然后注入接口。域D1的應用支撐平臺原型系統(tǒng)基于SHIRO 權限管理框架，通過集成CAS 實現具體應用的中心認證功能，使之變成CAS 客戶端，而不是由CAS 集成SHIRIO 功能，直接管理用戶授權及會話。在工程實踐中，兩者要加以區(qū)別［12，14］。

3.1 SHIRO核心概念

（1）Authentication：認證。

（2）Authorization：授權。

（3）Realm：從各類數據源獲取用戶、角色、權限數據，通過自定義機制實現認證、鑒權及授權，又稱之為域。多個Realm 通過設置策略實現相關功能。

（4）Principals：身份標識，具有唯一性，如工號、郵箱地址等。

（5）Credentials：憑證，主體在證明自己身份時提供的憑證，如密碼、票據等。

（6）Token：令牌，principals 與credentials 組合起來，構成身份驗證的基本且完整的要素（如UsernamePasswordToken）［14］。

3.2 SHIRO集成CAS方法步驟

（1）在新建或大量重構的應用中增加cas-client-core和shiro-cas 依賴（具體實現時，好的架構通常是在應用支撐平臺的系統(tǒng)集成應用中加入依賴），并在web.xml 中加入CAS客戶端過濾器。

（2）修改SHIRO 配置文件，配置Filter 和Realm，包括自定義權限過濾器、安全認證過濾器和認證器域，即shiro-Filter、casFilter、casRealm，關鍵配置如下［14］：

圖3 為運用本文所述方法快速開發(fā)的具有用戶集成功能的應用支撐基礎平臺原型系統(tǒng)，其實現了CAS 客戶端基本功能，能與CAS交互進行身份認證。

在原型系統(tǒng)中，CAS 服務器認證入口、應用支撐平臺（CAS 客戶端）認證入口以及CAS 客戶端跳轉至CAS 中心的網址分別如下：

（3）參考shiro-cas 包中CasRealm 類的源碼，繼承Cas-Realm、自定義認證類并重寫回調函數。

Fig.3 Prototype system of application support platform including user integration module圖3 具有用戶集成功能的應用支撐原型系統(tǒng)

4 結語

在大規(guī)模信息系統(tǒng)的用戶集成過程中，應把業(yè)務邏輯的分析和集成策略研究放在首要位置，以便解決邏輯沖突，避免單點故障和用戶權限錯配?；陂_源安全框架Apereo CAS 和Apache SHIRO 實現集成策略具有開發(fā)快速、安全穩(wěn)定及輕量級等優(yōu)點。未來的工作重點將放在原型系統(tǒng)的改進和實際工程應用上，通過實施大規(guī)模異構系統(tǒng)的用戶集成，大量收集與分析系統(tǒng)集成應用的狀態(tài)數據，以進一步檢驗與完善集成策略的完整性、正確性、安全性及運行效率。