陳 煒，柯水洲，李 強(qiáng)

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

0 引言

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

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

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

1 用戶(hù)集成邏輯問(wèn)題與策略研究

企事業(yè)單位在大規(guī)模組織運(yùn)用信息系統(tǒng)時(shí)，常常會(huì)遇到大規(guī)模用戶(hù)集成的問(wèn)題。為有效解決系統(tǒng)開(kāi)銷(xiāo)大、權(quán)限管理復(fù)雜等難題，消除單點(diǎn)沖突和權(quán)限錯(cuò)配，應(yīng)首先分析相關(guān)邏輯問(wèn)題，以便給出相應(yīng)策略和實(shí)現(xiàn)方法。

1.1 符號(hào)約定

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

1.2 用戶(hù)數(shù)據(jù)存儲(chǔ)域及用戶(hù)管理實(shí)現(xiàn)域

將新建或大量重構(gòu)的系統(tǒng)劃分到D1，原則上使用相同的綜合管理數(shù)據(jù)庫(kù)和應(yīng)用支撐平臺(tái)進(jìn)行用戶(hù)集中存儲(chǔ)與權(quán)限管理。對(duì)于域D2和D3，各自進(jìn)行獨(dú)立的用戶(hù)數(shù)據(jù)存儲(chǔ)與用戶(hù)權(quán)限管理［5］。

1.3 域之間用戶(hù)訪(fǎng)問(wèn)控制與認(rèn)證授權(quán)問(wèn)題

假設(shè)用戶(hù)U 既是D1中的用戶(hù)，又是D2中的用戶(hù)，如果用戶(hù)U 已通過(guò)中心認(rèn)證登錄了D1或D2中的任意一個(gè)應(yīng)用Ak，則可直接訪(fǎng)問(wèn)D1和D2中的其它應(yīng)用，而無(wú)需再次認(rèn)證。假設(shè)用戶(hù)U 是D1中的用戶(hù)，而不是D2中的用戶(hù)，其通過(guò)認(rèn)證中心登錄了D1中的應(yīng)用An，此時(shí)要訪(fǎng)問(wèn)D2中的應(yīng)用Am。Am檢測(cè)到用戶(hù)U 已通過(guò)認(rèn)證并從認(rèn)證中心獲取到了用戶(hù)信息，但Am通過(guò)查詢(xún)本地獨(dú)立的用戶(hù)數(shù)據(jù)，發(fā)現(xiàn)用戶(hù)U 不是本地用戶(hù)，則跳轉(zhuǎn)到Am應(yīng)用的本地認(rèn)證入口，提示用戶(hù)進(jìn)行認(rèn)證。

1.4 不同域用戶(hù)進(jìn)行綁定與映射的身份標(biāo)識(shí)

首先分析通過(guò)用戶(hù)名作為標(biāo)識(shí)進(jìn)行映射會(huì)產(chǎn)生的邏輯錯(cuò)誤。假設(shè)用戶(hù)U 通過(guò)認(rèn)證中心登錄了D1中的應(yīng)用An，正要訪(fǎng)問(wèn)D2中的應(yīng)用Am。Am檢測(cè)到用戶(hù)U 已通過(guò)認(rèn)證，并從認(rèn)證中心獲取了用戶(hù)名name1，此時(shí)可能出現(xiàn)3 種邏輯錯(cuò)誤：

（1）如果用戶(hù)U 是D2的用戶(hù)，但在D2中的用戶(hù)名為name2，將造成用戶(hù)U 無(wú)法正常訪(fǎng)問(wèn)Am。

（2）如果用戶(hù)U 不是D2的用戶(hù)，但恰好用戶(hù)V 以name1在D2中注冊(cè)過(guò)，將造成用戶(hù)U 可非法獲取用戶(hù)V 在Am中的權(quán)限，從而訪(fǎng)問(wèn)到用戶(hù)V 在Am中的操作視圖，導(dǎo)致登錄故障。

（3）如果用戶(hù)U 在Am中的用戶(hù)名為name2，用戶(hù)V 在Am中的用戶(hù)名為name1，此時(shí)表面上實(shí)現(xiàn)了認(rèn)證授權(quán)，但會(huì)造成用戶(hù)U 無(wú)法訪(fǎng)問(wèn)自己在Am中的操作視圖，卻可非法訪(fǎng)問(wèn)用戶(hù)V 在Am中的操作視圖，導(dǎo)致用戶(hù)操作權(quán)限錯(cuò)配。

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

此外，之所以要?jiǎng)?chuàng)建新的認(rèn)證中心數(shù)據(jù)庫(kù)，是因?yàn)槿绻J(rèn)證中心要針對(duì)不同應(yīng)用和數(shù)據(jù)源進(jìn)行認(rèn)證與交互，不僅會(huì)造成邏輯錯(cuò)誤，而且會(huì)增加集成開(kāi)發(fā)的工作量和復(fù)雜性，甚至降低系統(tǒng)性能。

1.5 用戶(hù)數(shù)據(jù)綁定與同步以及各域認(rèn)證入口訪(fǎng)問(wèn)控制

（1）用戶(hù)同步。各域的用戶(hù)范圍顯然是不同的，將中心認(rèn)證數(shù)據(jù)庫(kù)同步到各域數(shù)據(jù)庫(kù)不符合邏輯，增加了大量無(wú)效且冗余的用戶(hù)數(shù)據(jù)拷貝。因此，解決策略是將各域中用戶(hù)數(shù)據(jù)的少量關(guān)鍵信息同步到中心認(rèn)證數(shù)據(jù)庫(kù)。

（2）注冊(cè)同步。各域?qū)τ脩?hù)信息的內(nèi)容要求不一，但至少要有中心認(rèn)證數(shù)據(jù)庫(kù)所要求的用戶(hù)名、密碼、郵箱地址3 項(xiàng)內(nèi)容。在各域中，如果有新用戶(hù)創(chuàng)建、身份標(biāo)識(shí)（如電子郵箱地址）字段的增加或修改信息，則需要觸發(fā)事件，把用戶(hù)信息同步到中心認(rèn)證數(shù)據(jù)庫(kù)。如果用戶(hù)U 是D1中的用戶(hù)，在通過(guò)認(rèn)證中心驗(yàn)證的前提下又在D2中注冊(cè)時(shí)，應(yīng)從認(rèn)證中心自動(dòng)獲取D1中的身份標(biāo)識(shí)作為注冊(cè)字段。

（3）用戶(hù)綁定。用戶(hù)U 把在各域中的身份標(biāo)識(shí)（如電子郵箱地址）修改成自己常用的唯一身份標(biāo)識(shí)，即實(shí)現(xiàn)了同一個(gè)人在各域不同賬號(hào)的綁定映射。

（4）認(rèn)證入口。保留各域原有的登錄與認(rèn)證入口，當(dāng)用戶(hù)訪(fǎng)問(wèn)受限資源時(shí)，首先跳轉(zhuǎn)到認(rèn)證中心。如果未認(rèn)證，則重新跳轉(zhuǎn)到認(rèn)證中心登錄界面；如果認(rèn)證中心已驗(yàn)證通過(guò)，則進(jìn)入各域內(nèi)部。此時(shí)如果不是各域的有效用戶(hù)或不滿(mǎn)足該域的訪(fǎng)問(wèn)權(quán)限，則跳轉(zhuǎn)到各域原有認(rèn)證頁(yè)面或權(quán)限不滿(mǎn)足提示頁(yè)面。

不同應(yīng)用間用戶(hù)數(shù)據(jù)存儲(chǔ)及交互策略如圖1所示。

Fig.1 User data storage and interaction strategies of different application圖1 不同應(yīng)用間用戶(hù)數(shù)據(jù)存儲(chǔ)及交互策略

2 中心認(rèn)證Apereo CAS實(shí)現(xiàn)

CAS 是用于實(shí)現(xiàn)Web 中心認(rèn)證，使得單個(gè)用戶(hù)只提供一次憑證即可訪(fǎng)問(wèn)多個(gè)應(yīng)用的協(xié)議［7，12］。Apereo CAS 軟件由CAS服務(wù)器和CAS 客戶(hù)端［8，12］構(gòu)成，可支持CAS、SAML、OpenID、OAuth 等多種協(xié)議［10，12］。

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

CAS 的核心思想是應(yīng)用程序的用戶(hù)登錄及身份認(rèn)證交給CAS 服務(wù)器完成，用戶(hù)身份認(rèn)證成功后，其相應(yīng)角色和權(quán)限則可交給CAS 服務(wù)器進(jìn)行二次開(kāi)發(fā)集成，也可交給CAS 客戶(hù)端自己處理［12］。按照上文提出的集成策略，每個(gè)域?yàn)橐粋€(gè)CAS 客戶(hù)端，各域的用戶(hù)操作權(quán)限交給各域處理，即身份認(rèn)證的集中式管理和角色權(quán)限的分布式管理。CAS包括以下基本概念［7，12］：

（1）ST（Service Ticket）：代表訪(fǎng)問(wèn)許可唯一不可偽造的服務(wù)標(biāo)識(shí)碼，用戶(hù)認(rèn)證通過(guò)后，ST 由CAS 服務(wù)器發(fā)出，通過(guò)Http GET 請(qǐng)求的URL 參數(shù)傳輸，且只對(duì)當(dāng)前用戶(hù)有效。

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

（3）TGT（Ticket Grangting Ticket）：存儲(chǔ)在TGC 中，代表用戶(hù)的一次會(huì)話(huà)，也是用戶(hù)證明自己在CAS 服務(wù)器登錄過(guò)的憑證。

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

當(dāng)瀏覽器發(fā)出GET 請(qǐng)求要訪(fǎng)問(wèn)應(yīng)用An時(shí)，An（CAS 客戶(hù)端）攔截請(qǐng)求，把請(qǐng)求地址記錄下來(lái)暫存，重定向請(qǐng)求到CAS 服務(wù)器的登錄地址，并將An中CAS 客戶(hù)端程序的接口地址一并發(fā)給CAS服務(wù)器。

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

當(dāng)瀏覽器訪(fǎng)問(wèn)應(yīng)用Am時(shí)，Am將請(qǐng)求跳轉(zhuǎn)到CAS 服務(wù)器，CAS 服務(wù)器檢查T(mén)GC（cookie），發(fā)現(xiàn)已經(jīng)通過(guò)驗(yàn)證，則簽發(fā)ST 發(fā)送給Am的CAS 客戶(hù)端。Am的客戶(hù)端收到攜帶ST 的請(qǐng)求后，轉(zhuǎn)交CAS 服務(wù)器進(jìn)行驗(yàn)證。驗(yàn)證通過(guò)后，CAS 服務(wù)器將用戶(hù)信息回傳給Am的CAS 客戶(hù)端，由Am的CAS 客戶(hù)端與用戶(hù)建立會(huì)話(huà)，以網(wǎng)頁(yè)形式呈現(xiàn)被保護(hù)的信息資源給用戶(hù)。CAS 協(xié)議工作原理時(shí)序圖如圖2所示［11-13］。

2.3 CAS服務(wù)器搭建

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

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

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

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

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

3 CAS客戶(hù)端的Apache SHIRO 實(shí)現(xiàn)

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

3.1 SHIRO核心概念

（1）Authentication：認(rèn)證。

（2）Authorization：授權(quán)。

（3）Realm：從各類(lèi)數(shù)據(jù)源獲取用戶(hù)、角色、權(quán)限數(shù)據(jù)，通過(guò)自定義機(jī)制實(shí)現(xiàn)認(rèn)證、鑒權(quán)及授權(quán)，又稱(chēng)之為域。多個(gè)Realm 通過(guò)設(shè)置策略實(shí)現(xiàn)相關(guān)功能。

（4）Principals：身份標(biāo)識(shí)，具有唯一性，如工號(hào)、郵箱地址等。

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

（6）Token：令牌，principals 與credentials 組合起來(lái)，構(gòu)成身份驗(yàn)證的基本且完整的要素（如UsernamePasswordToken）［14］。

3.2 SHIRO集成CAS方法步驟

（1）在新建或大量重構(gòu)的應(yīng)用中增加cas-client-core和shiro-cas 依賴(lài)（具體實(shí)現(xiàn)時(shí)，好的架構(gòu)通常是在應(yīng)用支撐平臺(tái)的系統(tǒng)集成應(yīng)用中加入依賴(lài)），并在web.xml 中加入CAS客戶(hù)端過(guò)濾器。

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

圖3 為運(yùn)用本文所述方法快速開(kāi)發(fā)的具有用戶(hù)集成功能的應(yīng)用支撐基礎(chǔ)平臺(tái)原型系統(tǒng)，其實(shí)現(xiàn)了CAS 客戶(hù)端基本功能，能與CAS交互進(jìn)行身份認(rèn)證。

在原型系統(tǒng)中，CAS 服務(wù)器認(rèn)證入口、應(yīng)用支撐平臺(tái)（CAS 客戶(hù)端）認(rèn)證入口以及CAS 客戶(hù)端跳轉(zhuǎn)至CAS 中心的網(wǎng)址分別如下：

（3）參考shiro-cas 包中CasRealm 類(lèi)的源碼，繼承Cas-Realm、自定義認(rèn)證類(lèi)并重寫(xiě)回調(diào)函數(shù)。

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

4 結(jié)語(yǔ)

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