專利名稱：一種應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)證方法及裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及身份認(rèn)證技術(shù)，特別是涉及一種應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)證方法及 裝置。
背景技術(shù)：
通常，用戶訪問應(yīng)用系統(tǒng)時(shí)都需要進(jìn)行身份認(rèn)證，從而保證系統(tǒng)的安全性。 級聯(lián)認(rèn)證是指不同應(yīng)用系統(tǒng)之間實(shí)現(xiàn)用戶身份的相互識別。目前，不同應(yīng)用系 統(tǒng)之間的級聯(lián)認(rèn)證方式主要采用聯(lián)邦認(rèn)證的方式，是采用標(biāo)準(zhǔn)的協(xié)議進(jìn)行數(shù)據(jù)
傳輸，并且聯(lián)邦認(rèn)證有多種公開的標(biāo)準(zhǔn)，比如SAML( Security Assertion Markup Language,安全聲明標(biāo)記語言，是一種基于OASIS標(biāo)準(zhǔn)的可擴(kuò)展XML框架， 用于交換身份驗(yàn)證和授權(quán)信息，它允許在現(xiàn)代網(wǎng)絡(luò)環(huán)境中使用單一登錄功能) 等。但是，這些基于現(xiàn)有公開標(biāo)準(zhǔn)開發(fā)的聯(lián)邦認(rèn)證產(chǎn)品在兼容性上存在如下問 題
由于目前的聯(lián)邦認(rèn)證產(chǎn)品都是針對特定平臺系統(tǒng)間的認(rèn)證，即能夠級聯(lián)認(rèn) 證的所有系統(tǒng)都需要基于同 一個(gè)或同 一種平臺，而且基于這個(gè)平臺的系統(tǒng)間認(rèn) 證方式可能不適用于其他平臺的系統(tǒng)間認(rèn)證。也就是說，不同平臺適用的級聯(lián) 認(rèn)證方式也不同。因此，對于跨平臺應(yīng)用系統(tǒng)間的級聯(lián)iU正，目前的i人證產(chǎn)品 無法對基于不同平臺的系統(tǒng)實(shí)現(xiàn)相互認(rèn)證；而且，由于基于同一平臺的系統(tǒng)間 認(rèn)證，認(rèn)證產(chǎn)品與平臺綁定，平臺不同使用的認(rèn)證產(chǎn)品也需不同，這樣就必須 針對平臺來選擇聯(lián)邦認(rèn)證產(chǎn)品，因此目前的聯(lián)邦認(rèn)證產(chǎn)品都缺乏靈活性。
舉例說明，級聯(lián)認(rèn)證的系統(tǒng)是曱和乙，系統(tǒng)甲用戶通過系統(tǒng)甲訪問系統(tǒng)乙 時(shí)，系統(tǒng)乙需要對其進(jìn)行身份認(rèn)證；同樣，系統(tǒng)甲也需要對請求訪問的系統(tǒng)乙 用戶進(jìn)行認(rèn)證。如果系統(tǒng)曱和系統(tǒng)乙都基于同一個(gè)或同一種平臺，可以選擇針 對該平臺的聯(lián)邦認(rèn)證產(chǎn)品進(jìn)行相互認(rèn)證；如果分別基于不同的應(yīng)用平臺，則目
前的級^L認(rèn)證方式還無法實(shí)現(xiàn)。

發(fā)明內(nèi)容
本發(fā)明所要解決的技術(shù)問題是提供一種應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)證方法及裝置，以解決不同平臺應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)證問題。
為解決上述技術(shù)問題，根據(jù)本發(fā)明提供的具體實(shí)施例，本發(fā)明公開了以下
技術(shù)方案
一種應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)證方法，系統(tǒng)間的相互認(rèn)i正采用相同方法，其中 第 一 系統(tǒng)對第二系統(tǒng)的認(rèn)證包括
第 一 系統(tǒng)用戶通過第 一 系統(tǒng)發(fā)起訪問第二系統(tǒng)的請求；
第二系統(tǒng)根據(jù)當(dāng)前訪問的狀態(tài)判斷第一系統(tǒng)用戶是否已通過認(rèn)證，如果 是，則允許訪問；如果否，則第二系統(tǒng)將所述請求重定向到第一系統(tǒng)，由第一 系統(tǒng)完成該用戶的內(nèi)部iU正；
當(dāng)?shù)?一 系統(tǒng)通過該用戶的內(nèi)部認(rèn)證后，向第二系統(tǒng)反饋認(rèn)證成功消息，第 二系統(tǒng)允許第 一 系統(tǒng)用戶訪問。
優(yōu)選的，第二系統(tǒng)將所述請求重定向到第一系統(tǒng)的步驟包括第二系統(tǒng)構(gòu) 建請求tokens消息，并攜帶應(yīng)用ID發(fā)送到第一系統(tǒng)；其中，所述請求tokens 消息包括第 一 系統(tǒng)用戶請求的URL和應(yīng)用注銷的URL。
優(yōu)選的，所述請求tokens消息還包括時(shí)間戳和隨機(jī)數(shù)，第一系統(tǒng)根據(jù)所述 時(shí)間戳和隨機(jī)數(shù)進(jìn)行安全驗(yàn)證。
優(yōu)選的，第二系統(tǒng)構(gòu)建請求tokens消息之后，還包括第二系統(tǒng)才艮據(jù)與第 一系統(tǒng)協(xié)商的加解密算法，對所述請求tokens消息進(jìn)行加密，并且所述加解密 算法可配置。
優(yōu)選的，如果第二系統(tǒng)判斷第一系統(tǒng)用戶已通過iU正，還包括第二系統(tǒng) 繼續(xù)判斷當(dāng)前請求的Session ID與已通過認(rèn)證的Session ID是否相同，如果不 相同，則拒絕訪問。
優(yōu)選的，所述第一系統(tǒng)和第二系統(tǒng)分別采用過濾器方式進(jìn)行相互認(rèn)證。
一種應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)證裝置，所述級聯(lián)認(rèn)證裝置分別設(shè)置在每個(gè)應(yīng)用 系統(tǒng)端，包括
認(rèn)證發(fā)送單元，用于向?qū)Ψ桨l(fā)送訪問請求；
認(rèn)證接收單元，用于接收對方發(fā)來的訪問請求，并調(diào)用狀態(tài)維護(hù)單元才艮據(jù) 當(dāng)前訪問的狀態(tài)判斷對方用戶是否已通過認(rèn)證，如果是，則完成認(rèn)證4妻收功能； 如果否，則觸發(fā)認(rèn)證處理單元；還用于接收對方發(fā)來的重定向請求，并觸發(fā)認(rèn)證處理單元進(jìn)行處理；
認(rèn)證處理單元，針對所述訪問請求，用于將接收的.訪問請求重定向到對方，
由對方完成認(rèn)證；針對所述重定向請求，用于對接收的重定向請求進(jìn)行內(nèi)部認(rèn) 證，認(rèn)證通過后，向?qū)Ψ椒答佌J(rèn)證成功消息； 狀態(tài)維護(hù)單元，用于維護(hù)當(dāng)前訪問的狀態(tài)。
優(yōu)選的，所述認(rèn)i正處理單元的重定向請求包4舌請求tokens消息和應(yīng)用 ID,其中請求tokens消息包括第一系統(tǒng)訪問請求的URL和應(yīng)用注銷的URL。
優(yōu)選的，所述請求tokens消息還包括時(shí)間戳和隨機(jī)數(shù)。
優(yōu)選的，所述裝置還包括加解密單元，用于對所述請求tokens消息進(jìn)行 加解密處理，其中所述加解密算法可配置。
優(yōu)選的，所述裝置還包括安全處理單元，用于根據(jù)請求tokens消息中的 時(shí)間戳和隨機(jī)數(shù)進(jìn)行安全驗(yàn)證。
優(yōu)選的，如果認(rèn)證接收單元判斷對方用戶已通過認(rèn)證，則所述認(rèn)證接收單 元繼續(xù)判斷當(dāng)前請求的Session ID與已通過認(rèn)證的Session ID是否相同，如果 不相同，則拒絕訪問。
根據(jù)本發(fā)明提供的具體實(shí)施例，本發(fā)明公開了以下技術(shù)效果
首先，本發(fā)明提供了一種通用的應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)證方法，可以實(shí)現(xiàn)兩 個(gè)或多個(gè)不同平臺或相同平臺之間的應(yīng)用系統(tǒng)的用戶身份認(rèn)證。所述i人證方法 為當(dāng)系統(tǒng)曱的用戶從系統(tǒng)曱上發(fā)起訪問系統(tǒng)乙的請求時(shí)，系統(tǒng)乙首先判斷用 戶是否通過認(rèn)證，如果未通過認(rèn)證，則系統(tǒng)乙直接重定向到系統(tǒng)曱，由系統(tǒng)曱 完成認(rèn)證，如果系統(tǒng)曱通過該用戶的認(rèn)證則反饋認(rèn)證成功消息到系統(tǒng)乙，系統(tǒng) 乙則認(rèn)為該用戶為合法用戶，允許其訪問。反之，如果系統(tǒng)乙上的用戶訪問系 統(tǒng)曱，也釆用相同的流程。所述方法有效解決了現(xiàn)有的各種聯(lián)邦認(rèn)證產(chǎn)品互不 兼容的問題。
其次，上述級聯(lián):i人i正過程中，采用tokens方式傳遞參數(shù)，即直沖妻在URL (Uniform Resoure Locator,統(tǒng)一資源定位器)地址后面攜帶自定義的重定向 參數(shù)，而現(xiàn)有的聯(lián)邦熱證產(chǎn)品都是在底層釆用標(biāo)準(zhǔn)的協(xié)議進(jìn)行數(shù)據(jù)傳輸，本發(fā) 明與底層傳輸相比具有簡單易實(shí)現(xiàn)等特點(diǎn)。
再次，聯(lián)邦認(rèn)證產(chǎn)品的認(rèn)證數(shù)據(jù)傳輸加密方式是固定的，用戶不可選擇；而本發(fā)明對數(shù)據(jù)加密方式不做任何限制，由用戶根據(jù)安全性的需要自行選擇加 密方式，有更好的靈活性與可擴(kuò)展性。
最后，本發(fā)明除采用加密方式外，還采用時(shí)間戳、隨機(jī)數(shù)等措施來保證數(shù)
據(jù)傳輸安全，即在tokens消息中攜帶時(shí)間戳和隨機(jī)數(shù)來防止傳輸數(shù)據(jù)被篡改或 泄露。


圖1是本發(fā)明所述應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)證方法實(shí)施例流程圖； 圖2是本發(fā)明所述應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)證裝置實(shí)施例結(jié)構(gòu)框圖； 圖3是本發(fā)明實(shí)施例所述系統(tǒng)間的級聯(lián)認(rèn)證裝置處理流程圖。
具體實(shí)施例方式
為使本發(fā)明的上述目的、特征和優(yōu)點(diǎn)能夠更加明顯易懂，下面結(jié)合附圖和具體實(shí)施方式
對本發(fā)明作進(jìn)一步詳細(xì)的說明。
目前不同平臺應(yīng)用系統(tǒng)之間需要級聯(lián)以形成一個(gè)整體，其相互之間需要進(jìn) 行認(rèn)證。本發(fā)明提供了一種通用的應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)證方法，可以實(shí)現(xiàn)兩個(gè) 或多個(gè)不同平臺或相同平臺之間的應(yīng)用系統(tǒng)的用戶身份認(rèn)證。本發(fā)明實(shí)現(xiàn)的前 提是應(yīng)用系統(tǒng)之間的認(rèn)證是相互信任的，即系統(tǒng)曱的用戶如果訪問系統(tǒng)乙，則 系統(tǒng)乙認(rèn)為系統(tǒng)曱的認(rèn)證方式是可信任的。
認(rèn)證原理如下當(dāng)系統(tǒng)甲的用戶從系統(tǒng)曱上發(fā)起訪問系統(tǒng)乙的請求時(shí)，系 統(tǒng)乙首先判斷用戶是否通過認(rèn)證，如果未通過認(rèn)證，則系統(tǒng)乙直接重定向到系 統(tǒng)甲，由系統(tǒng)曱完成認(rèn)證，如果系統(tǒng)曱通過該用戶的認(rèn)證則反饋認(rèn)證成功消息 到系統(tǒng)乙，系統(tǒng)乙則認(rèn)為該用戶為合法用戶，允許其訪問。反之，如果系統(tǒng)乙 上的用戶訪問系統(tǒng)曱，也采用相同的流程。
下面將以系統(tǒng)曱和系統(tǒng)乙之間的相互認(rèn)證為例進(jìn)行詳細(xì)說明，其中，系統(tǒng) 曱和系統(tǒng)乙并不特指某個(gè)系統(tǒng)，而是為了便于說明而加以區(qū)別。
參照圖1,所述應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)證方法流程圖。其中，系統(tǒng)甲和系統(tǒng) 乙可以基于同一種或同一個(gè)平臺，也可以基于不同平臺。由于甲對乙的認(rèn)證流 程與乙對甲的認(rèn)證流程相同，因此以系統(tǒng)甲用戶請求訪問系統(tǒng)乙，由系統(tǒng)乙對 系統(tǒng)曱用戶進(jìn)行認(rèn)證為例說明。在實(shí)際應(yīng)用中，系統(tǒng)曱和系統(tǒng)乙都采用過濾器方式實(shí)現(xiàn)整個(gè)認(rèn)證過程，具體流程如下步驟IOI，當(dāng)系統(tǒng)曱用戶需要訪問系統(tǒng)乙時(shí)，從系統(tǒng)曱發(fā)起訪問請求。在 過濾器方式下，用戶通過系統(tǒng)甲的過濾器發(fā)送請求，訪問系統(tǒng)乙的URL資源。步驟102,系統(tǒng)乙判斷系統(tǒng)曱用戶是否已通過認(rèn)證，如果是，則執(zhí)行步驟 103;如果否，則執(zhí)行步驟104。在過濾器方式下，系統(tǒng)乙的過濾器截?cái)嗾埱螅?檢驗(yàn)該用戶是否已經(jīng)認(rèn)證。在整個(gè)認(rèn)證過程中，系統(tǒng)乙會(huì)維護(hù)一張當(dāng)前訪問的狀態(tài)表，如果訪問用戶 在本次通信連接中已通過認(rèn)證，則會(huì)記錄在狀態(tài)表中。在級聯(lián)環(huán)境下，系統(tǒng)間 的一次連接過程中可以發(fā)起多次訪問請求，如果在本次連4妄中已通過i^證，則 后續(xù)的請求過程視為已認(rèn)證，但是每次連接都需要重新進(jìn)行認(rèn)證。步驟103，如果已經(jīng)認(rèn)證，則過濾器將請求轉(zhuǎn)發(fā)到系統(tǒng)乙中，允許該用戶 i方問系統(tǒng)乙。優(yōu)選的，為增加認(rèn)證的安全性，如果系統(tǒng)曱用戶已經(jīng)通過認(rèn)證，則系統(tǒng)乙 過濾器還會(huì)繼續(xù)驗(yàn)證當(dāng)前請求的Session ID與已通過認(rèn)證的Session ID是否相 同，如果不相同，則拒絕訪問。Session—般都譯作時(shí)域。在計(jì)算機(jī)專業(yè)術(shù)語中，Session是指一個(gè)終端用 戶與交互系統(tǒng)進(jìn)行通信的時(shí)間間隔，通常指從注冊進(jìn)入系統(tǒng)到注銷退出系統(tǒng)之 間所經(jīng)過的時(shí)間。具體到Web中的Session指的就是用戶在瀏覽某個(gè)網(wǎng)站時(shí)， 從進(jìn)入網(wǎng)站到瀏覽器關(guān)閉所經(jīng)過的這段時(shí)間，也就是用戶瀏覽這個(gè)網(wǎng)站所花費(fèi) 的時(shí)間。因此從上述的定義中可以看到，Session實(shí)際上是一個(gè)特定的時(shí)間概 念。需要注意的是， 一個(gè)Session的概念需要包括特定的客戶端、特定的服務(wù) 器端以及不中斷的操作時(shí)間。例如，A用戶和C服務(wù)器建立連接時(shí)所處的 Session同B用戶和C服務(wù)器中建立連接時(shí)所處的Sessions是兩個(gè)不同的 Session。步驟104，如果沒有認(rèn)證，則系統(tǒng)乙的過濾器將所述請求重定向到系統(tǒng)曱， 由系統(tǒng)曱完成該用戶的內(nèi)部^人iit。所述重定向的具體過程是系統(tǒng)乙的過濾器構(gòu)建請求tokens消息，將時(shí)間 戳、隨機(jī)數(shù)以及用戶請求的URL、應(yīng)用注銷的URL等參數(shù)按照規(guī)定格式組合 成字符串，通過用戶選擇的加密協(xié)議加密該信息，并攜帶應(yīng)用ID生成重定向請求，發(fā)送到系統(tǒng)曱過濾器的URL。在tokens消息中，用戶請求的URL是指 用戶需要訪問的應(yīng)用系統(tǒng)地址；應(yīng)用注銷的URL是指用戶通過認(rèn)證后訪問到 的應(yīng)用系統(tǒng)，該應(yīng)用系統(tǒng)自身的注銷地址；重定向請求中的應(yīng)用ID是指為標(biāo) 識應(yīng)用系統(tǒng)而分配的ID。其中，用戶請求的URL與應(yīng)用ID是——映射關(guān)系， 并不一定相同?，F(xiàn)有技術(shù)中，聯(lián)邦認(rèn)證產(chǎn)品在認(rèn)證過程中的數(shù)據(jù)是在底層傳輸，即采用標(biāo) 準(zhǔn)的協(xié)i義進(jìn)4亍凄t據(jù)傳輸，類似于在TCP (Transmission Control Protocol,傳輸 控制協(xié)議)層上再構(gòu)筑一個(gè)協(xié)議層用來身份認(rèn)證。而本發(fā)明優(yōu)選的，采用tokens 方式傳遞參數(shù)，所述Tokens就是在HTTP(Hyper Text Transfer Protocol,超文 本傳輸協(xié)議)的URL地址后面攜帶自定義的字符串。與底層傳輸相比，tokens 方式傳輸數(shù)據(jù)具有簡單易實(shí)現(xiàn)等特點(diǎn)。現(xiàn)有技術(shù)中，聯(lián)邦認(rèn)證產(chǎn)品的認(rèn)證數(shù)據(jù)傳輸加密方式是固定的，用戶不可 選擇。而本發(fā)明優(yōu)選的，對數(shù)據(jù)加密方式不做任何限制，由用戶根據(jù)安全性的 需要自行選4奪加密方式，有更好的靈活性與可擴(kuò)展性。這種可配置的加解密方 式包括第一，用戶可以根據(jù)預(yù)先編制好的一系列加解密函數(shù)進(jìn)行選擇；第二， 用戶也可以自己編寫加解密函數(shù)，在程序中調(diào)用自己的加解密函數(shù)就可以。需 要說明的是，這里的"用戶，，是指本發(fā)明所述級聯(lián)認(rèn)證產(chǎn)品的使用用戶，不同 于系統(tǒng)甲用戶。本發(fā)明優(yōu)選的，在請求tokens消息中加入時(shí)間戳和隨機(jī)數(shù)來增加婆:據(jù)傳輸 的安全性，防止數(shù)據(jù)在傳輸過程中^^皮非法篡改或信息泄露。步驟105,系統(tǒng)曱的過濾器解密所述請求tokens消息，取得相應(yīng)信息，然 后對系統(tǒng)甲用戶進(jìn)行內(nèi)部認(rèn)證。每個(gè)應(yīng)用系統(tǒng)可以采用自己的內(nèi)部認(rèn)i正方式， 因?yàn)橄到y(tǒng)內(nèi)的認(rèn)證不會(huì)影響整個(gè)級聯(lián)系統(tǒng)的認(rèn)證。優(yōu)選的，過濾器還會(huì)將tokens消息中的時(shí)間戳與當(dāng)前時(shí)間比較來檢查是否 超時(shí)，同時(shí)還檢查隨機(jī)數(shù)是否被篡改，從而保證數(shù)據(jù)傳輸?shù)陌踩?。步驟106,當(dāng)-險(xiǎn)證通過后，系統(tǒng)曱的過濾器又將該用戶ID等標(biāo)識用戶身 份的用戶信息，以及時(shí)間戳、隨機(jī)數(shù)等信息按照規(guī)定格式組合加密，然后返回 癥合系統(tǒng)乙。步驟107,系統(tǒng)乙的過濾器收到系統(tǒng)曱返回的成功響應(yīng)信息后，解密獲得用戶ID等用戶信息，然后傳遞到系統(tǒng)乙。系統(tǒng)乙利用所述用戶信息進(jìn)行單點(diǎn) 登錄初始化工作，完成整個(gè)認(rèn)證過程。 .上述流程是系統(tǒng)曱用戶訪問系統(tǒng)乙的認(rèn)證流禾呈，同樣，系統(tǒng)乙用戶訪問系 統(tǒng)曱也按照上述流程執(zhí)行。而且，上述認(rèn)證流程還適用于多個(gè)不同平臺或相同 平臺之間的應(yīng)用系統(tǒng)的用戶身份認(rèn)證，本發(fā)明在此不限定具體的應(yīng)用情況。針對上述級聯(lián)認(rèn)證方法，本發(fā)明還提供了一種應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)證裝置實(shí)施例。參照圖2，是所述應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)i正裝置結(jié)構(gòu)框圖。所述級聯(lián)認(rèn)證裝置設(shè)置于每個(gè)應(yīng)用系統(tǒng)端，系統(tǒng)之間的相互認(rèn)證由每個(gè)系統(tǒng)的認(rèn)證裝置完 成。因此，所述認(rèn)證裝置同時(shí)具有發(fā)起認(rèn)證請求和接收認(rèn)證請求進(jìn)行認(rèn)證的雙 重功能。所述級聯(lián)認(rèn)證裝置主要包括認(rèn)證發(fā)送單元201、認(rèn)證接收單元202、認(rèn)證 處理單元203和狀態(tài)維護(hù)單元204。認(rèn)證發(fā)送單元201負(fù)責(zé)向?qū)Ψ降募壜?lián)認(rèn)證裝置發(fā)送訪問請求。認(rèn)證接收單元202負(fù)責(zé)接收對方發(fā)來的訪問請求，并調(diào)用狀態(tài)維護(hù)單元 204,根據(jù)當(dāng)前訪問的狀態(tài)判斷對方用戶是否已通過認(rèn)證，如果是，則完成認(rèn) 證接收功能；如果否，則觸發(fā)認(rèn)證處理單元203。認(rèn)證接收單元202還用于接 收對方發(fā)來的重定向請求，并觸發(fā)認(rèn)證處理單元203進(jìn)行處理。優(yōu)選的，如果認(rèn)證接收單元203判斷對方用戶已通過認(rèn)證，則繼續(xù)判斷當(dāng) 前請求的Session ID與已通過認(rèn)證的Session ID是否相同，如果不相同，則拒 絕訪問，從而保證了認(rèn)證的安全性。認(rèn)證處理單元203負(fù)責(zé)實(shí)現(xiàn)整個(gè)認(rèn)證處理流程。針對對方發(fā)來的訪問請 求，用于將接收的訪問請求重定向到對方的級聯(lián)i^證裝置，由對方完成認(rèn)證； 針對重定向請求，用于對接收的重定向請求進(jìn)行內(nèi)部認(rèn)證，認(rèn)證通過后，向?qū)?方反4貴iU正成功消息。狀態(tài)維護(hù)單元204負(fù)責(zé)維護(hù)當(dāng)前訪問的狀態(tài)，并判斷用戶刷新狀態(tài)是否超 時(shí)，如果超時(shí)則斷開連接。優(yōu)選的，所述認(rèn)證處理單元203采用tokens方式傳遞參數(shù)。認(rèn)證處理單元 203構(gòu)建請求tokens消息，請求tokens消息包括用戶請求的URL、應(yīng)用注銷 的URL等參數(shù)，為了保證安全性還包括時(shí)間戳和隨機(jī)數(shù)。認(rèn)證處理單元203將請求tokens消息和應(yīng)用ID按照規(guī)定格式組合成字符串作為重定向請求，發(fā) 送到對方的級聯(lián)認(rèn)證寒置。優(yōu)選的，所述級聯(lián)認(rèn)證裝置還包括加解密單元205，負(fù)責(zé)根據(jù)認(rèn)證處理單 元203的調(diào)用，對tokens消息進(jìn)行加解密處理。其中，加解密單元205實(shí)現(xiàn)的 各種加解密算法可配置，即用戶可以根據(jù)預(yù)先編制好的一系列加解密函數(shù)進(jìn)行 選擇，或者自己編寫加解密函數(shù)。優(yōu)選的，所述級聯(lián)認(rèn)i正裝置還包括安全處理單元206,負(fù)責(zé)將tokens消息 中的時(shí)間戳與當(dāng)前時(shí)間比較來檢查是否超時(shí)，同時(shí)還檢查隨機(jī)數(shù)是否被篡改， 從而保證數(shù)據(jù)傳輸?shù)陌踩?。上面對級?lián)認(rèn)證裝置內(nèi)各個(gè)單元的功能進(jìn)行了綜合說明，下面將通過認(rèn)證 過程中系統(tǒng)間各單元的處理流程進(jìn)行詳細(xì)說明。參照圖3，是系統(tǒng)間的級聯(lián)認(rèn) 證裝置處理流程圖。仍以系統(tǒng)甲和系統(tǒng)乙為例說明。系統(tǒng)曱和系統(tǒng)乙分別部署了相同的級聯(lián)認(rèn) 證裝置，系統(tǒng)曱和系統(tǒng)乙之間的相互認(rèn)證由級聯(lián)認(rèn)i正裝置曱和級聯(lián)認(rèn)證裝置乙 配合完成。為描述清楚筒捷，圖3中僅列出了涉及本次處理流程的單元，對應(yīng) 級聯(lián)認(rèn)證裝置曱的單元包括認(rèn)證發(fā)送單元301 、認(rèn)證接收單元302、認(rèn)證處理 單元303、加解密單元304和安全處理單元305,對應(yīng)級聯(lián)認(rèn)證裝置乙的單元 包括認(rèn)證發(fā)送單元311、認(rèn)證接收單元312、認(rèn)證處理單元313、狀態(tài)維護(hù)單 元314、加解密單元315和安全處理單元316。當(dāng)系統(tǒng)曱用戶請求訪問系統(tǒng)乙時(shí)，處理流程如下1 、系統(tǒng)甲通過認(rèn)證發(fā)送單元301發(fā)起訪問請求；2、 系統(tǒng)乙的認(rèn)證接收單元312接收到所述訪問請求后，調(diào)用狀態(tài)維護(hù)單 元314根據(jù)當(dāng)前訪問的狀態(tài)判斷系統(tǒng)甲用戶是否已通過認(rèn)證，如果是，則繼續(xù) 驗(yàn)證當(dāng)前請求的Session ID與已通過認(rèn)證的Session ID是否相同，如果不相同， 則拒絕訪問；如果相同，則將請求轉(zhuǎn)發(fā)到系統(tǒng)乙中，允許該用戶訪問系統(tǒng)乙；3、 如果系統(tǒng)曱用戶未通過認(rèn)證，則觸發(fā)認(rèn)證處理單元313;系統(tǒng)乙的認(rèn) 證處理單元313構(gòu)建請求tokens消息，將時(shí)間戳、隨才幾數(shù)以及用戶請求的URL、 應(yīng)用注銷的URL等參數(shù)按照規(guī)定格式組合成字符串，調(diào)用加解密單元315加 密該信息，并攜帶應(yīng)用ID生成重定向請求，通過i^證發(fā)送單元311發(fā)送到系統(tǒng)曱；4、 系統(tǒng)甲的認(rèn)證接收單元302接收到所述重定向請求后，調(diào)用加解密單 元304對請求tokens消息進(jìn)行解密處理，并調(diào)用安全處理單元305對請求tokens 消息中的時(shí)間戳、隨機(jī)數(shù)進(jìn)行安全檢驗(yàn)；解密得到相應(yīng)信息后，調(diào)用認(rèn)證處理 單元303對該用戶進(jìn)行內(nèi)部認(rèn)證；認(rèn)證通過后，認(rèn)證處理單元303將該用戶ID 等標(biāo)識用戶身份的用戶信息，以及時(shí)間戳、隨機(jī)數(shù)等信息按照規(guī)定格式組合成 成功反饋tokens消息，并利用加解密單元304進(jìn)行加密，然后通過認(rèn)證發(fā)送單 元301返回系統(tǒng)乙；5、 系統(tǒng)乙的認(rèn)證接收單元312接收所述成功反饋消息，利用加解密單元 315解密獲得用戶ID,傳遞給系統(tǒng)乙，并調(diào)用安全處理單元316對請求tokens 消息中的時(shí)間戳、隨機(jī)數(shù)進(jìn)行安全檢驗(yàn)；系統(tǒng)乙利用所述用戶信息進(jìn)行單點(diǎn)登 錄初始化工作，完成整個(gè)認(rèn)證過程。上述單元數(shù)據(jù)處理流程清楚說明了系統(tǒng)乙對系統(tǒng)甲用戶的單向認(rèn)證過程， 同樣，系統(tǒng)曱對系統(tǒng)乙用戶的認(rèn)證也可參照圖3,將圖示中的曱乙調(diào)換即可， 在此不再詳述。圖2、圖3所示裝置中未詳述的部分可以參見圖1所示方法的相關(guān)部分， 為了篇幅考慮，在此不再詳述。以上對本發(fā)明所提供的一種應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)證方法及裝置，進(jìn)行了詳實(shí)施例的說明只是用于幫助理解本發(fā)明的方法及其核心思想；同時(shí)，對于本領(lǐng) 域的一般技術(shù)人員，依據(jù)本發(fā)明的思想，在具體實(shí)施方式
及應(yīng)用范圍上均會(huì)有 改變之處。綜上所述，本說明書內(nèi)容不應(yīng)理解為對本發(fā)明的限制。
權(quán)利要求
1、一種應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)證方法，其特征在于，系統(tǒng)間的相互認(rèn)證采用相同方法，其中第一系統(tǒng)對第二系統(tǒng)的認(rèn)證包括第一系統(tǒng)用戶通過第一系統(tǒng)發(fā)起訪問第二系統(tǒng)的請求；第二系統(tǒng)根據(jù)當(dāng)前訪問的狀態(tài)判斷第一系統(tǒng)用戶是否已通過認(rèn)證，如果是，則允許訪問；如果否，則第二系統(tǒng)將所述請求重定向到第一系統(tǒng)，由第一系統(tǒng)完成該用戶的內(nèi)部認(rèn)證；當(dāng)?shù)谝幌到y(tǒng)通過該用戶的內(nèi)部認(rèn)證后，向第二系統(tǒng)反饋認(rèn)證成功消息，第二系統(tǒng)允許第一系統(tǒng)用戶訪問。
2、 根據(jù)權(quán)利要求1所述的方法，其特征在于，第二系統(tǒng)將所述請求重定 向到第 一 系統(tǒng)的步驟包括第二系統(tǒng)構(gòu)建請求tokens消息，并攜帶應(yīng)用ID發(fā) 送到第一系統(tǒng)；其中，所述請求tokens消息包括第一系統(tǒng)用戶請求的URL和 應(yīng)用注銷的URL。
3、 根據(jù)權(quán)利要求2所述的方法，其特征在于所述請求tokens消息還包 括時(shí)間戳和隨機(jī)數(shù)，第一系統(tǒng)根據(jù)所述時(shí)間戳和隨機(jī)數(shù)進(jìn)行安全驗(yàn)證。
4、 根據(jù)權(quán)利要求2或3所述的方法，其特征在于，第二系統(tǒng)構(gòu)建請求tokens 消息之后，還包括第二系統(tǒng)根據(jù)與第一系統(tǒng)協(xié)商的加解密算法，對所述請求 tokens消息進(jìn)行加密，并且所述加解密算法可配置。
5、 根據(jù)權(quán)利要求1所述的方法，其特征在于，如果第二系統(tǒng)判斷第一系 統(tǒng)用戶已通過認(rèn)證，還包括第二系統(tǒng)繼續(xù)判斷當(dāng)前請求的Session ID與已通 過認(rèn)證的Session ID是否相同，如果不相同，則拒絕訪問。
6、 根據(jù)權(quán)利要求1所述的方法，其特征在于所述第一系統(tǒng)和第二系統(tǒng) 分別采用過濾器方式進(jìn)行相互認(rèn)證。
7、 一種應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)證裝置，其特征在于，所述級聯(lián)認(rèn)證裝置分 別設(shè)置在每個(gè)應(yīng)用系統(tǒng)端，包括認(rèn)證發(fā)送單元，用于向?qū)Ψ桨l(fā)送訪問請求；認(rèn)證接收單元，用于接收對方發(fā)來的訪問請求，并調(diào)用狀態(tài)維護(hù)單元根據(jù) 當(dāng)前訪問的狀態(tài)判斷對方用戶是否已通過認(rèn)證，如果是，則完成認(rèn)證^接收功能； 如果否，則觸發(fā)認(rèn)證處理單元；還用于接收對方發(fā)來的重定向請求，并觸發(fā)認(rèn)證處理單元進(jìn)行處理；認(rèn)證處瑪單元，針對所述訪問請求，用于將接收的訪問請求重定向到對方，由對方完成認(rèn)證；針對所述重定向請求，用于對4妄收的重定向請求進(jìn)4亍內(nèi)部認(rèn) 證，i人證通過后，向?qū)Ψ椒础┵F認(rèn)i正成功消息； 狀態(tài)維護(hù)單元，用于維護(hù)當(dāng)前訪問的狀態(tài)。
8、 根據(jù)權(quán)利要求7所述的級聯(lián)認(rèn)證裝置，其特征在于所述認(rèn)^t處理單 元的重定向請求包括請求tokens消息和應(yīng)用ID ，其中請求tokens消息包括 第———系統(tǒng)訪問請求的URL和應(yīng)用注銷的URL。
9、 根據(jù)權(quán)利要求8所述的級聯(lián)認(rèn)證裝置，其特征在于所述請求tokens 消息還包括時(shí)間戳和隨機(jī)數(shù)。
10、 根據(jù)權(quán)利要求8、 9所述的級聯(lián)認(rèn)證裝置，其特征在于，還包括加 解密單元，用于對所述請求tokens消息進(jìn)行加解密處理，其中所述加解密算法 可配置。
11、 根據(jù)權(quán)利要求9所述的級Jf關(guān)認(rèn)證裝置，其特征在于，還包括安全處 理單元，用于根據(jù)請求tokens消息中的時(shí)間戳和隨機(jī)數(shù)進(jìn)行安全驗(yàn)證。
12、 根據(jù)權(quán)利要求7所述的級聯(lián)認(rèn)證裝置，其特征在于如果認(rèn)證接收單 元判斷對方用戶已通過認(rèn)證，則所述認(rèn)證接收單元繼續(xù)判斷當(dāng)前請求的 Session ID與已通過認(rèn)證的Session ID是否相同，如果不相同，則拒絕訪問。
全文摘要
本發(fā)明公開了一種應(yīng)用系統(tǒng)間的級聯(lián)認(rèn)證方法及裝置，可以實(shí)現(xiàn)兩個(gè)或多個(gè)不同平臺或相同平臺之間的應(yīng)用系統(tǒng)的用戶身份認(rèn)證。所述認(rèn)證方法包括當(dāng)系統(tǒng)甲的用戶從系統(tǒng)甲上發(fā)起訪問系統(tǒng)乙的請求時(shí)，系統(tǒng)乙首先判斷用戶是否通過認(rèn)證，如果未通過認(rèn)證，則系統(tǒng)乙直接重定向到系統(tǒng)甲，由系統(tǒng)甲完成認(rèn)證，如果系統(tǒng)甲通過該用戶的認(rèn)證則反饋認(rèn)證成功消息到系統(tǒng)乙，系統(tǒng)乙則認(rèn)為該用戶為合法用戶，允許其訪問。反之，如果系統(tǒng)乙上的用戶訪問系統(tǒng)甲，也采用相同的流程。在相互認(rèn)證的流程過程中，數(shù)據(jù)交互可采用各種加密算法，用戶可以自己選擇加解密算法，增加系統(tǒng)的靈活性與可擴(kuò)展性。
文檔編號H04L9/32GK101222335SQ200810057498
公開日2008年7月16日 申請日期2008年2月2日 優(yōu)先權(quán)日2008年2月2日
發(fā)明者劉建明, 崔丙鋒, 王繼業(yè), 范鵬展, 陳德勝, 魏曉菁 申請人:國電信息中心