王 小 紅
(福建經(jīng)濟(jì)學(xué)校 計(jì)算機(jī)教研室,福州 350002 )
通常企業(yè)內(nèi)員工需要使用企業(yè)內(nèi)的多個(gè)業(yè)務(wù)系統(tǒng),要想進(jìn)入各個(gè)業(yè)務(wù)系統(tǒng),就需要員工分別輸入系統(tǒng)的用戶名和密碼,對(duì)企業(yè)員工來(lái)說(shuō)使用很不方便,同時(shí)還要記憶多個(gè)賬戶信息,大大降低了工作效率.并且很多人為了方便記憶,通常將系統(tǒng)賬戶設(shè)置成相同的用戶名和密碼,這樣又容易造成企業(yè)信息外泄,系統(tǒng)的安全受到威脅.原先的用戶登錄方式已經(jīng)不能滿足企業(yè)目前及未來(lái)業(yè)務(wù)發(fā)展的需求.為了解決以上企業(yè)業(yè)務(wù)系統(tǒng)的整合問(wèn)題,提出了單點(diǎn)登錄(Single Sign-on,簡(jiǎn)稱SSO)技術(shù)的解決方案.SSO的含義是:在企業(yè)內(nèi)的多個(gè)應(yīng)用系統(tǒng)中,用戶實(shí)現(xiàn)“一次登錄,全網(wǎng)通行”,而無(wú)需進(jìn)行多次登錄.單點(diǎn)登錄的認(rèn)證數(shù)據(jù)可以來(lái)源于企業(yè)門戶系統(tǒng),而門戶系統(tǒng)中的用戶屬性信息在身份認(rèn)證完成后,通過(guò)單點(diǎn)登錄系統(tǒng)傳遞給后臺(tái)的應(yīng)用系統(tǒng),作為業(yè)務(wù)系統(tǒng)進(jìn)一步進(jìn)行訪問(wèn)控制管理的基礎(chǔ).
實(shí)現(xiàn)SSO的技術(shù)有很多,有基于代理人、基于經(jīng)紀(jì)人、基于網(wǎng)關(guān)和Cookie等,針對(duì)不同架構(gòu)系統(tǒng)使用不同的認(rèn)證方式.現(xiàn)介紹幾個(gè)常用方式:
(1) LTPA.LTPA(Lightweight Third-Party Authentication,中文全稱是輕量級(jí)第三方認(rèn)證)是適用于IBM WebSphere和Domino產(chǎn)品的SSO應(yīng)用,可以通過(guò)配置實(shí)現(xiàn)用戶的單點(diǎn)登陸功能.當(dāng)用戶請(qǐng)求獲取WebSphere資源時(shí),必須首先通過(guò)認(rèn)證服務(wù),待用戶驗(yàn)證通過(guò)后生成LTPA Cookie(即LTPA Token);用戶在發(fā)送包含LTPA Cookie的HTTP請(qǐng)求時(shí),后臺(tái)的WebSphere服務(wù)器通過(guò)連接收到請(qǐng)求,同時(shí)使用其共享的加密密鑰副本解密cookie并驗(yàn)證Cookie的完整性,這時(shí)通過(guò)Cookie中提供的有效標(biāo)識(shí)信息來(lái)識(shí)別登錄用戶的合法身份.LTPA技術(shù)是IBM的標(biāo)準(zhǔn),它支持IBM產(chǎn)品之間的身份驗(yàn)證(圖1).
(2) Form-Based方式.基于表單的單點(diǎn)登陸方式,這種方式是通過(guò)模擬用戶憑證提交,將業(yè)務(wù)系統(tǒng)相關(guān)的用戶憑證通過(guò) Form 提交的方式,傳遞給業(yè)務(wù)系統(tǒng)認(rèn)證模塊.認(rèn)證服務(wù)通過(guò)webseal新建的賬號(hào)信息,透明地登陸到支持表單認(rèn)證的子系統(tǒng)中,并顯示子系統(tǒng)的原始用戶名.具體的認(rèn)證時(shí)序圖如圖2所示.
圖1 LTPA單點(diǎn)登錄流程
圖2 基于表單的單點(diǎn)登錄時(shí)序圖
(3) Cookie-based方式.在Web領(lǐng)域較常使用Cookie認(rèn)證機(jī)制,并適用于SUN Portal或Oracle Portal的SSO應(yīng)用.在相同域名間通過(guò)Cookie和令牌傳遞,實(shí)現(xiàn)登錄訪問(wèn)(圖3);令牌環(huán)方式的最大好處在于無(wú)需統(tǒng)一的驗(yàn)證服務(wù)器,是“多點(diǎn)驗(yàn)證模式”的主力實(shí)現(xiàn)技術(shù)[1],各個(gè)服務(wù)器都通過(guò)統(tǒng)一的密鑰對(duì)令牌進(jìn)行加密解密,所以該方式具有安全性高,穩(wěn)定性好,性能消耗低等優(yōu)點(diǎn);其缺點(diǎn)就是必須保證各臺(tái)應(yīng)用服務(wù)器同域.對(duì)于跨域的登錄,Cookies自己并沒有這個(gè)能力,但可以結(jié)合其他形式實(shí)現(xiàn)跨域的SSO.
圖3 基于Cookie單點(diǎn)登錄流程
(4) SSO方案比較.以上3種實(shí)現(xiàn)單點(diǎn)登陸的方式所能夠支持的應(yīng)用系統(tǒng)、優(yōu)缺點(diǎn)以及建議如表1所示:
表1 單點(diǎn)登錄方案對(duì)比表
可見,目前大多數(shù)企業(yè)內(nèi)匯集眾多基于Web的應(yīng)用系統(tǒng),各個(gè)應(yīng)用系統(tǒng)都有自己獨(dú)立的門戶網(wǎng)站和異構(gòu)平臺(tái),可考慮利用Cookie在不同站點(diǎn)的傳遞機(jī)制.它是一種基于HTTP重定向和票據(jù)的集中式認(rèn)證方式;結(jié)合了企業(yè)要求具有的方便靈活、低成本、跨地區(qū)(域)的特質(zhì).通??紤]采用基于Cookie的單點(diǎn)登錄認(rèn)證機(jī)制.
研究分析用戶單點(diǎn)登錄采用基于Cookie的認(rèn)證方式,所有參與單點(diǎn)登錄應(yīng)用系統(tǒng)的訪問(wèn)地址要求采用域名,并且要隸屬于同一個(gè)DNS域.若無(wú)法統(tǒng)一域名,也可以實(shí)現(xiàn)單點(diǎn)登錄(見下面“跨域解決”).所有應(yīng)用系統(tǒng)的登錄認(rèn)證都通過(guò)統(tǒng)一認(rèn)證中心(一般企業(yè)是門戶系統(tǒng)來(lái)?yè)?dān)當(dāng))來(lái)實(shí)現(xiàn).各應(yīng)用系統(tǒng)需要簡(jiǎn)單改造一下本系統(tǒng)的登錄頁(yè)面,把本系統(tǒng)登錄頁(yè)面中輸入用戶名和密碼的提交地址(即Form的Action)變更為統(tǒng)一認(rèn)證中心的登錄認(rèn)證地址或者直接把本系統(tǒng)的登錄頁(yè)面重定向到認(rèn)證中心的登錄頁(yè)面,待用戶身份認(rèn)證通過(guò)后,用戶的相關(guān)信息加密后由認(rèn)證中心以名為UNI_SESS的COOKIE[2]方式傳給客戶端瀏覽器,并重定向回各應(yīng)用系統(tǒng).各應(yīng)用系統(tǒng)分析從瀏覽器傳過(guò)來(lái)的所有COOKIE,從中提取名為UNI_SESS的COOKIE,拿來(lái)解密,根據(jù)解密后的UNI_SESS值對(duì)用戶訪問(wèn)本應(yīng)用系統(tǒng)的權(quán)限進(jìn)行認(rèn)證,認(rèn)證通過(guò)則創(chuàng)建本應(yīng)用系統(tǒng)的會(huì)話并允許用戶訪問(wèn)本系統(tǒng),否則導(dǎo)向到統(tǒng)一認(rèn)證中心作登錄.
下面是假設(shè)用戶登錄A應(yīng)用系統(tǒng)時(shí)進(jìn)行統(tǒng)一認(rèn)證的流程示意圖(其中左側(cè)的流程是A系統(tǒng)要做的,右側(cè)的流程是認(rèn)證中心要做的),如圖4所示:
圖4 Cookie認(rèn)證流程
統(tǒng)一認(rèn)證流程說(shuō)明如下:
1) 用戶通過(guò)瀏覽器訪問(wèn)應(yīng)用系統(tǒng)A;
2) A系統(tǒng)檢測(cè)用戶有無(wú)有效的本系統(tǒng)的會(huì)話信息,有則直接進(jìn)入A系統(tǒng);
3) 無(wú)的話應(yīng)用系統(tǒng)A檢測(cè)是否有UNI_SESS這個(gè)Cookie值;
4) 無(wú)則重定向到認(rèn)證中心的登錄頁(yè)面,同時(shí)把A系統(tǒng)的訪問(wèn)地址作為參數(shù)放在URL中傳給認(rèn)證中心系統(tǒng),待登錄成功后重定向回來(lái)(例如某企業(yè):http:∥企業(yè)門戶系統(tǒng)的服務(wù)器地址/names.nsf?login&redirectto=sysurl,其中的sysurl是經(jīng)過(guò)編碼的訪問(wèn)A系統(tǒng)的首頁(yè)的url).
5) 有則調(diào)用解密接口解密Cookie值UNI_SESS,解密后的結(jié)果是這樣的:cn=姓名&userid=用戶編號(hào)&userdept=部門&useroccupation=職務(wù)&usersys=應(yīng)用編號(hào)&userfun=操作功能 &logintime=登錄時(shí)間.uid是16位數(shù)字的用戶的唯一編號(hào);部門含有用戶所在的部門的所有層次關(guān)系,各層次間用/分隔,最低一級(jí)層次在前,最高一級(jí)層次在最后,例如,**辦公室/**分公司/省公司;每個(gè)應(yīng)用系統(tǒng)都有一個(gè)事先約定好的編號(hào),應(yīng)用編號(hào)是用逗號(hào)分隔的,允許該用戶訪問(wèn)的所有應(yīng)用系統(tǒng)的編號(hào)列表,編號(hào)之間用逗號(hào)分隔,例如,1,3,7,代表用戶可以訪問(wèn)編號(hào)為1或3或7的系統(tǒng);
6) 看本系統(tǒng)的編號(hào)是否羅列在應(yīng)用編號(hào)列表中,不在列表中則轉(zhuǎn)至3);
7) 若系統(tǒng)編號(hào)有在列表中,則比較登錄時(shí)間與當(dāng)前系統(tǒng)服務(wù)器時(shí)間,若登錄時(shí)間比當(dāng)前系統(tǒng)服務(wù)器時(shí)間早4 h以上,則不讓用戶登錄,轉(zhuǎn)至3);
8) 檢查該用戶在本系統(tǒng)的權(quán)限情況,若本系統(tǒng)允許該用戶訪問(wèn),則生成本系統(tǒng)的用戶會(huì)話認(rèn)證信息,展示相關(guān)的頁(yè)面.
若應(yīng)用系統(tǒng)A與統(tǒng)一認(rèn)證中心不在同一個(gè)DNS域內(nèi)[3],則由于Cookie值的域限制問(wèn)題,用戶在統(tǒng)一認(rèn)證中心認(rèn)證成功后獲得的認(rèn)證Cookie值,A應(yīng)用系統(tǒng)無(wú)法獲取,因此無(wú)法采用Cookie的方式來(lái)進(jìn)行單點(diǎn)登錄,但可以采用HTTP POST 的方法實(shí)現(xiàn).A應(yīng)用系統(tǒng)需要專門設(shè)計(jì)一個(gè)頁(yè)面(可以由原來(lái)的登錄頁(yè)面經(jīng)過(guò)簡(jiǎn)單改造得到),用來(lái)接收統(tǒng)一認(rèn)證中心提交過(guò)來(lái)的經(jīng)過(guò)加密的認(rèn)證信息,原來(lái)是從Cookie值中取認(rèn)證信息,變更為從POST提交的數(shù)據(jù)中取認(rèn)證信息.就是在第4)步中的登錄URL寫成http:∥企業(yè)門戶系統(tǒng)的服務(wù)器地址/main.nsf/unilogin?openagent&redirectto=sysurl,其中的sysurl就是登錄成功后要把UNI_SESS值進(jìn)行POST提交的A系統(tǒng)認(rèn)證URL地址.
通常,在傳輸信道中,Cookie的傳輸形式是明文,信息太暴露,并且客戶端存儲(chǔ)是以文件形式,加重了安全威脅.因此,可采用PBE(passwod-based enerypt)加密算法[4],使用密匙才能解密讀出明文,有效地解決傳輸中存在的安全問(wèn)題(表2).
表2 Cookie內(nèi)容
對(duì)接入的信息子系統(tǒng)進(jìn)行注冊(cè),注冊(cè)的信息有:子系統(tǒng)的名稱和簡(jiǎn)稱,是否需要數(shù)據(jù)同步,同步通知URL和Socket約定,是否需要單點(diǎn)登錄,單點(diǎn)方式以及登錄時(shí)的URL.
(1) 接口規(guī)范.登錄的時(shí)候,同時(shí)設(shè)置Cookie的UNI_SESS的加密串,訪問(wèn)其他業(yè)務(wù)系統(tǒng)時(shí),業(yè)務(wù)系統(tǒng)取Cookie的UNI_SESS的加密串,解密后的格式為 cn=姓名&userid=用戶編號(hào)&userdept=部門&useroccupation=職務(wù)&usersys=應(yīng)用編號(hào)&userfun=操作功能&logintime=登錄時(shí)間.
如果取到用戶信息正確,則無(wú)須驗(yàn)證,直接進(jìn)入業(yè)務(wù)系統(tǒng) ,否則,導(dǎo)航到業(yè)務(wù)系統(tǒng)的認(rèn)證界面.代碼實(shí)現(xiàn)如下:
∥ *** Cookies ***
function writeCookie(name.value){
exp=new Date();
exp.setTime(exp.gerTime()+86400*1000*30));
document.cookie=name+"="+escape(value)+";expires="+
exp.toGMTString()+";path=/"
}
function readCookie(name){
var search;
search=name+"=";
offset=document.cookie.indexOf(search);
if(offset !=-1){
offset+=search.length;
end=document.cookie.indexOf(";",offset0;
if(end==-1{
end=document.cookie.length;
}
return unescape(document.cookie.substring(offset.end));
}else{
return"";
}
}
(2) 后臺(tái)登錄表單改造.改造后的登錄表單至少需要包含3個(gè)設(shè)計(jì)元素:用戶名輸入框、密碼輸入框和登錄按鈕.用戶名輸入框的name屬性必須為Usemame,密碼輸入框的name屬性必須為Password,登錄按鈕的type屬性為Submit.
登錄表單的onload事件代碼如下:
var loginurl="∥yourserver/login.jsp";
var posturl="∥企業(yè)門戶系統(tǒng)的服務(wù)器地址/main.nsf/unilogin?open&redirectto="+escape(loginurl);
document.forms[0].action="∥企業(yè)門戶系統(tǒng)的服務(wù)器地址/servlet/UniLogin?Open&RedirectTo="+escape(posturl);
各應(yīng)用系統(tǒng)需要把loginurl的值換成自己系統(tǒng)的接收認(rèn)證信息的url,該url就是經(jīng)過(guò)代碼改造的原登錄表單的action地址.
(3) 部分實(shí)現(xiàn)代碼.如實(shí)現(xiàn)讀取用戶信息的代碼如下:
dim strUniSess,objCrypt,userinfo
setobjCrypt=server.createobject("yccrypt.bfcrypt")
strUniSess=Request.Cookies("UNI_SESS")
strUniSess=objCrypt.UrlDecode(strUniSess,True)
response.write "UNI_SESS:" & strUniSess & "
"
if strUniSess="" then
response.write "Not Login"
else userinfo=objCrypt.YCDecrypt(strUniSess,"xycqgwgkuvi87860988")
response.write "UserInfo:" & userinfo & "
"
end if
以企業(yè)內(nèi)大量Web應(yīng)用系統(tǒng)為背景,研究對(duì)比了幾種常用單點(diǎn)登錄技術(shù)方案,分析和研究基于Cookie的單點(diǎn)登錄方案,并采用HTTP POST 的方法來(lái)解決跨域問(wèn)題,為企業(yè)提供了一個(gè)方便快捷,管理輕松,成本低,安全性高的單點(diǎn)登錄認(rèn)證機(jī)制.
參考文獻(xiàn):
[1] 葉中奇, 劉向華.探秘企業(yè)級(jí)SSO[J/OL].2010-07-21.[2013/10/28].http:∥bbs.vsharing.com/Information/KM/1189024-1.html
[2] 馮偉華,劉亞麗.基于Cookie的統(tǒng)一認(rèn)證系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)工程與設(shè)計(jì),2010(6):40-44
[3] STAN REIMER,CONAN KEZEMA,MIKE MULCARE,et al.Windows Server 2008 活動(dòng)目錄應(yīng)用指南[M].北京:人民郵電出版社,2010
[4] 王曉東.計(jì)算機(jī)算法設(shè)計(jì)與分析[M].北京:電子工業(yè)出版社,2001