一種多維度的數(shù)字化校園安全性設(shè)計

一種多維度的數(shù)字化校園安全性設(shè)計

0web集成平臺數(shù)字化校園與大量web應用程序系統(tǒng)緊密相連。統(tǒng)一身份認證是必須解決的問題。單點登錄(SingleSign-on,簡稱SSO)是實現(xiàn)統(tǒng)一身份認證的有效方式,比較成熟和穩(wěn)定的解決方案有IBM公司的Websphere、SUN公司的SunJavaSystemAccessManager、Microsoft公司的passport、BEA的WebLogic以及一些基于SAML的產(chǎn)品,如OPENSAML、SourceID等。這些SSO方案的側(cè)重點不一樣,實現(xiàn)機制也不盡相同。但對于Web應用這種對系統(tǒng)簡潔性需求較高的應用來說,一些解決方案并不非常合適,原因是它們對現(xiàn)有Web應用集成帶來的代價過大,產(chǎn)生的負面效應尤為突出。校園網(wǎng)是數(shù)字化校園運轉(zhuǎn)的基礎(chǔ),具有結(jié)構(gòu)相對簡單,用戶群比較單純,數(shù)據(jù)傳輸質(zhì)量較高的特點,在數(shù)字化校園中應用的SSO系統(tǒng)應盡可能減少對原有Web應用的改造,加快身份驗證的速度,并能保證較高的安全性。本文針對數(shù)字化校園的特點,提出一種基于Cookie與臨時碼的SSO解決方案,闡述該方案的設(shè)計思路、工作流程和關(guān)鍵技術(shù),討論該方案的安全問題,最后介紹該方案的實現(xiàn)與應用情況。1登錄單號的實現(xiàn)模式和戰(zhàn)略1.1創(chuàng)建全局login百分點典型的SSO系統(tǒng)都遵循一種通用的模式,由入口檢查單元(gatekeeper)、身份認證單元(authenticator)和用戶憑證存儲單元(usercredentialsstore)三個部分組成。交互關(guān)系如下:(1)gatekeeper檢查到用戶準備訪問受到保護的Web資源時,它先檢查該用戶是否已為該Web應用創(chuàng)建好一個loginsession,若沒有,gatekeeper再檢查是否已建立一個和authenticator相關(guān)的全局SSOsession;若沒有,該用戶被重定向到authenticator的登錄頁面,并要求該用戶提供憑證信息(用戶名和密碼等)。(2)authenticator接收該用戶提供的憑證信息,并通過身份認證系統(tǒng)驗證該用戶。(3)若驗證成功,它將創(chuàng)建一個全局loginsession,導向至gatekeeper,并在該用戶的Web應用中為其創(chuàng)建一個loginsession。(4)authenticator和gatekeepers之間通過多種方式進行交互,如共享cookie方式。1.2實現(xiàn)平臺認證的可行性基于Web的單點登錄實現(xiàn)策略主要有三種:ticket憑證、Web請求代理、密碼代理。這三種實現(xiàn)策略的比較如表1所示。以上對基于Web的單點登錄模式和策略進行了比較。可以看出,在已有應用的基礎(chǔ)上集成實現(xiàn)SSO系統(tǒng),基于Web請求代理的認證策略對原有應用系統(tǒng)的改造代價較小,且登錄服務器的負載相比密碼代理策略小很多。本文基于數(shù)字化校園的特點,在借鑒基于Web請求代理策略基本思想的基礎(chǔ)上,給出一個適用于數(shù)字化校園的簡單的SSO系統(tǒng)實現(xiàn)方案。2基于臨時代碼的簡單sso系統(tǒng)2.1系統(tǒng)訪問方案本方案主要針對數(shù)字化校園而設(shè)計,實現(xiàn)的關(guān)鍵在于臨時碼,原理如圖1所示。基本思路為:(1)用戶登錄到認證服務器后,認證服務器將為其生成一個臨時碼,并將此臨時碼與用戶信息進行加密,存儲到用戶端Cookies中;(2)用戶初次訪問Web應用時,Web應用首先將提交過來的加密信息進行還原,并存儲當前憑證(用戶名與臨時碼);(3)Web應用將此憑證提交到認證服務器進行核實,若驗證正確,則允許用戶訪問資源;否則刪除(2)中存儲的憑證,并作出相應動作;(4)當用戶退出時,認證服務器將為其生成另一個臨時碼(更新臨時碼表);(5)當用戶退出后再重新訪問Web應用,在(3)中驗證臨時碼時,臨時碼此時失效。方案中臨時碼是用戶狀態(tài)的唯一標識,可以認為用戶的臨時碼無改變的話,用戶狀態(tài)也沒有改變。同時由于臨時碼是隨機生成的,若能保證臨時碼的安全性,就能保證登錄用戶的合法性。2.2工作流(1)產(chǎn)品密碼和臨時碼用戶提交用戶名、密碼和驗證碼(以圖片形式隨機生成)到認證服務器驗證,信息提交采用隱藏表單域?qū)崿F(xiàn)。若提交信息正確,認證服務器隨機生成一個臨時碼,并將此臨時碼與用戶信息進行加密,存儲到用戶端Cookies中;若否,則返回錯誤提示或按要求跳轉(zhuǎn)。(2)第一次訪問web應用程序的過程見圖3此時,Web應用域下的Cookies中沒有記錄用戶信息和憑證,要求用戶跳轉(zhuǎn)到認證服務器確認用戶是否已經(jīng)登錄。(3)web應用防護經(jīng)歷首次訪問Web應用系統(tǒng)較為復雜的認證過程后,用戶再次訪問該Web應用的過程非常簡單。此時,用戶憑證在Web應用中存在,只需要向認證服務器進行憑證驗證即可。(4)臨時碼改變的問題當用戶退出認證服務器,或用戶在其它機器上進行登錄,認證服務器中的臨時碼都將發(fā)生改變,此時保存在客戶端的憑證已經(jīng)失效,無法再以該用戶的身份訪問Web應用系統(tǒng)。2.3主要功能模塊(1)系統(tǒng)總體過程認證服務器端完成的主要任務是:用戶登錄、用戶退出、用戶獲取臨時碼、為Web應用檢驗臨時碼。用戶登錄過程:①檢查提交的用戶名、密碼、驗證碼的完整性;②若正確,則檢查提交的驗證碼和Session的驗證碼對應性;③若對應,再檢查用戶名、密碼的對應性;④若對應,為用戶更新隨機生成的臨時碼,與用戶信息加密后寫入客戶端Cookies中(服務器端Cookies中保存副本)。以上條件不成立時立即跳轉(zhuǎn)到登錄錯誤對應地址。用戶退出過程:①請求退出的鏈接中提供退出成功后所要轉(zhuǎn)向的地址;②檢查Cookies中用戶狀態(tài)信息,是否登錄;③已登錄,則為用戶更新隨機生成的臨時碼,擦除Cookies中狀態(tài)信息;若否,則直接轉(zhuǎn)入④;④跳轉(zhuǎn)到退出成功后對應的地址。用戶獲取臨時碼過程:①請求臨時碼的鏈接中提供用戶在Web應用中請求的頁面地址;②檢查Cookies中用戶狀態(tài)信息,是否登錄;③已登錄,則提取臨時碼,將用戶名、臨時碼等信息添加到提供的Web應用頁面地址中;否則,將未知用戶信息添加到提交的Web應用頁面地址中;④跳轉(zhuǎn)到修改后的Web頁面對應地址。為Web應用檢驗臨時碼過程:①Web應用請求驗證用戶名、臨時碼的鏈接中提供了用戶名、臨時碼;②檢查用戶名、臨時碼對應性;③以XML方式返回檢查結(jié)果。(2)客戶端臨時碼解決檢查和憑證檢查客戶端組件首先檢查頁面參數(shù),看用戶是否從身份驗證系統(tǒng)獲取完憑證跳轉(zhuǎn)回來的;如是,則讀取頁面參數(shù),檢查客戶端臨時碼(先進行解密);如客戶端臨時碼正確,且憑證中表明用戶已經(jīng)登錄,則在Cookies中記錄相應信息,否則跳過?？蛻舳私M件接著檢查用戶憑證,存在則聯(lián)系認證服務器檢驗憑證;否則生存客戶端臨時碼,在Session中記錄,并要求用戶跳轉(zhuǎn)到認證服務器獲取憑證。2.4關(guān)鍵技術(shù)(1)全局變量特性的應用臨時碼是本方案的關(guān)鍵,它是證明用戶身份以及狀態(tài)所必須的依據(jù),認證服務器讀取臨時碼的速度將主要決定整個方案的響應速度。由于臨時碼需要是有態(tài)的,而且是跨Session的,傳統(tǒng)的做法是將臨時碼存放在使用磁盤作為載體的數(shù)據(jù)庫中。而經(jīng)驗表明,數(shù)據(jù)庫的讀寫往往成為整個系統(tǒng)效率的瓶頸。本方案利用.NET程序的靜態(tài)全局變量特性,將臨時碼表保存在認證系統(tǒng)的內(nèi)存中,加快了認證的響應速度。同時,由于認證系統(tǒng)是基于Web的,也就是說臨時碼表的生存期依賴于系統(tǒng)的進程的生存期,這可以很方便地在大多數(shù)的Internet信息服務器中設(shè)置,降低了管理難度。(2)web應用信息的提取由于身份認證系統(tǒng)與各Web應用屬于不同的域,Cookies機制無法實現(xiàn)跨域間的信息傳遞,URL重寫機制容易遇到信息偽造問題。在本方案中,用戶在首次訪問Web應用系統(tǒng)時,首先需要到身份管理系統(tǒng)中索取憑證,利用基于“瀏覽器跳轉(zhuǎn)”特性,將認證系統(tǒng)與各Web應用之間的通訊信息封裝在URL中,通過頁面參數(shù)進行信息傳遞。由于我院校園網(wǎng)是千兆網(wǎng),用戶在訪問其中的Web應用系統(tǒng)時不會對這2次跳轉(zhuǎn)有明顯的感覺。(3)web應用與認證服務器之間通訊方案見圖3Web應用在獲得并記錄用戶憑證后,將直接與認證服務器通訊以檢查用戶憑證是否仍有效,而無須再次要求用戶進行跳轉(zhuǎn),這將大大提升響應速度和用戶體驗。Web應用與認證服務器之間通訊基于HTTP,通過頁面參數(shù)提交檢查請求,采用XML為載體返回檢驗結(jié)果。該方式的特點是靈活易擴展,但會增大傳輸?shù)臄?shù)據(jù)量。對于質(zhì)量較高的網(wǎng)絡(如千兆校園網(wǎng))來說,該方式不會對系統(tǒng)的響應時間有太大影響,卻能大大降低系統(tǒng)擴展的難度。2.5安全考慮(1)中庭性用戶登錄認證服務器時,除需要提交用戶名和密碼外,還需要提交驗證碼,減緩登錄速度,有效防止暴力破解。(2)防止用戶信息被篡改完整性問題主要Web應用接收用戶請求時,由于用戶端Cookies存儲的是加密信息,能防止用戶信息被篡改。同時,Web應用端接收到用戶憑證后,不管自身是否存有用戶憑證,都轉(zhuǎn)入認證服務器進行驗證,保證了憑證的完整性。(3)防止重放攻擊重放攻擊威脅發(fā)生在用戶登錄認證服務器和用戶請求Web應用資源時,由于方案中用戶每次登錄或退出認證系統(tǒng),都將隨機生成(更新)臨時碼,對二次登錄、退出后重新登錄等情況進行了限制,有效防止了重放攻擊。(4)防止了中間人讀取會話內(nèi)容認證服務器將用戶名和臨時碼加密發(fā)送到用戶端存儲,在一定程度上防止了中間人讀取會話內(nèi)容。但為了加快頁面跳轉(zhuǎn)速度,方案中Web應用與認證服務器之間通訊采用明文傳輸,這可能成為中間人攻擊的切入點。2.6客戶端組件建設(shè)根據(jù)本方案,本文以.NETFramework1.1為平臺,采用C#語言進行實現(xiàn)。認證服務器端采用WindowsServer2003+.NETFramework1.1+IIS6.0+SQLServer2005實現(xiàn),安放項目文件后,配置用戶數(shù)據(jù)表所在SQL數(shù)據(jù)庫的連接信息,并配置好IIS進行啟動與驗證。客戶端組件以源碼形式提供,它只有一個公開方法,用于檢查用戶身份以及將用戶名和臨時碼寫到特定的Cookies中。針對不同的Web開發(fā)技術(shù),分別開發(fā)了基于.NET、ASP和JSP的三組客戶端組件。該系統(tǒng)在我校數(shù)字校園應用中,為校園BBS、視頻點播、教務管理、學工系統(tǒng)、OA系統(tǒng)、實踐教學系統(tǒng)提供單點登錄,效果非常理想。該系統(tǒng)的主要特點有:(1)不使用平臺依賴的SSO方案,完全使用自行定制的身份認證系統(tǒng)服務端和客戶端,以滿足現(xiàn)存的基于不同平臺的Web應用的需要;(2)身份認證系統(tǒng)的用戶管理依賴于校園網(wǎng)現(xiàn)有的網(wǎng)絡管理系統(tǒng),不提供對用戶帳號信息修改的功能,減少因身份認證系統(tǒng)被入侵而導致校園管理系統(tǒng)安全性的下降;(3)用戶通過身份認證系統(tǒng)登錄后,只獲得其真實身份的認證,用戶對各個信息系統(tǒng)的訪問控制還是由各個Web應用自行負責。認證服務器對用戶的登錄、退出動作做簡單的日志記錄;(4)用戶以登錄時認證服務器為其生成的臨時碼