淺談文獻數(shù)據(jù)庫系統(tǒng)幾種常用的自動認(rèn)證方式

李健虹

(天津中環(huán)創(chuàng)新科技有限公司 天津300190)

應(yīng)用技術(shù)

淺談文獻數(shù)據(jù)庫系統(tǒng)幾種常用的自動認(rèn)證方式

李健虹

(天津中環(huán)創(chuàng)新科技有限公司 天津300190)

針對實際應(yīng)用中用戶對文獻數(shù)據(jù)庫系統(tǒng)自動身份認(rèn)證的需求，結(jié)合工作實際，對幾種常用自動認(rèn)證方式進行分析對比，得出其各自不同的認(rèn)證機制、優(yōu)勢、不足以及適用環(huán)境，在方便用戶使用的同時為文獻資源整合服務(wù)提供了一定的借鑒。

文獻數(shù)據(jù)庫 自動認(rèn)證 OPENAPI 認(rèn)證接口

文獻數(shù)據(jù)庫系統(tǒng)為了保護自有知識產(chǎn)權(quán)，通過采用授權(quán)方式使用，比如 CNKI、讀秀、維普等。科技文獻平臺集成了多種類型文獻數(shù)據(jù)庫，授權(quán)方式包括基于 IP范圍、用戶口令和密碼、主機綁定等 3種方式。由于整合了多種類型異構(gòu)數(shù)據(jù)庫，為了方便管理，文獻平臺需要對平臺用戶進行身份認(rèn)證。用戶使用多個數(shù)據(jù)庫系統(tǒng)時，需要分別輸入用戶名和密碼登陸，由于不同系統(tǒng)對口令的管理要求不同，用戶不得不記住多個用戶名和密碼，這給用戶帶來了麻煩。而為方便記憶選擇簡單口令時，安全性就降低。自動身份認(rèn)證是解決這一問題的有效辦法。本文重點討論了幾種常用的自動認(rèn)證方式及其各自優(yōu)缺點。另外，目前文獻數(shù)據(jù)庫基本上均為 WEB服務(wù)方式，絕大多數(shù)為 B/S結(jié)構(gòu)，傳統(tǒng)單機版及 C/S結(jié)構(gòu)數(shù)據(jù)庫已相對較少，因此本文主要探討基于WEB方式的文獻數(shù)據(jù)庫自動認(rèn)證方式。

1 WEB瀏覽器提供的自動認(rèn)證方式

WEB瀏覽器為文獻數(shù)據(jù)庫或其他WEB應(yīng)用系統(tǒng)提供了用戶自動認(rèn)證的功能，并得到普遍應(yīng)用，目前多種瀏覽器均提供“自動保存口令”功能，比如 IE瀏覽器、火狐瀏覽器、360瀏覽器等，瀏覽器自動記錄用戶在不同鏈接中輸入的用戶名和口令，當(dāng)再次瀏覽該鏈接時，用戶只需輸入用戶名的部分字符，系統(tǒng)就會彈出完整用戶名，并自動填寫相應(yīng)的密碼。

自動認(rèn)證通過 Cookies來實現(xiàn)。Cookies指網(wǎng)站為了辨別用戶身份、進行 Session跟蹤而儲存在用戶本地終端上的數(shù)據(jù)(通常經(jīng)過加密)，當(dāng)用戶瀏覽某個數(shù)據(jù)庫資源商的遠(yuǎn)程系統(tǒng)時，就會收到Web Server發(fā)來的一個惟一用戶ID的非常小的文本文件，并置于用戶硬盤上，這便是 Cookies文件。Cookies文件記錄登錄者的用戶名、口令、瀏覽過的網(wǎng)頁、網(wǎng)頁停留時間等信息。當(dāng)用戶再次登錄該網(wǎng)站時，網(wǎng)站通過讀取電腦硬盤上的 Cookies，提取上次登錄相關(guān)信息，并執(zhí)行相應(yīng)的操作，使用戶無需輸入ID、密碼就直接登錄并訪問服務(wù)器上的資源，或在頁面顯示“歡迎你”標(biāo)語。

Cookies從本質(zhì)上講，可以看作是用戶的身份證，其所保存的信息片斷以“名/值”對的形式儲存，一個“名/值”對應(yīng)一條命名的數(shù)據(jù)，且經(jīng)過加密處理，信息只能由提供它的服務(wù)器來讀取，且不能作為代碼執(zhí)行，也不會傳送病毒。同時，服務(wù)器不能從其他服務(wù)器的Cookies文件中提取信息，只能獲取自己放在用戶計算機中的信息片段，因此Cookies在保障賬戶隱私方面具有一定的安全性。但是對于用戶而言，在方便的同時，也帶來了安全隱患，目前僅限于在用戶本機上操作，具有較大的局限性。

2 基于FORM表單的模擬自動認(rèn)證方式

隨著互聯(lián)網(wǎng)技術(shù)的快速發(fā)展，目前主流的文獻數(shù)據(jù)庫應(yīng)用系統(tǒng)基本以 B/S模式為主，盡管不同的數(shù)據(jù)庫系統(tǒng)身份認(rèn)證頁面看起來各不相同，但大部分采用 HTTP POST方式，即將用戶身份信息提交給服務(wù)器來完成認(rèn)證，其中 HTML FORM 表單是通常采用的提交手段，主要將用戶名、密碼等用戶填寫的表單信息提交至身份認(rèn)證頁面，通過后臺校驗程序自動完成對用戶身份的判定，以完成對用戶的認(rèn)證。HTML FORM表單作為收集Web信息最常用的方法，包括3個基本組成部分：標(biāo)簽、控件和按鈕。其中表單標(biāo)簽包含了處理表單數(shù)據(jù)所用服務(wù)程序的 URL以及數(shù)據(jù)向服務(wù)器提交的方法；FORM表單的 Action屬性指定了包含處理邏輯的認(rèn)證頁面，驗證提交的行為命令；而 Method指定提交表單的方法，即POST和 GET兩種方法。控件包括文本、單選、多選、下拉選項等 HTML或服務(wù)器端控件，我們通常所填寫的用戶名、密碼等信息便作為表單控件進行提交。最后表單的提交是通過按鈕來完成的，通常為 SUBMIT按鈕，或通過普通 Button結(jié)合腳本代碼來完成。登錄頁面發(fā)送用戶輸入信息采用格式為HTTP頭+name＝value序列的POST格式，當(dāng)服務(wù)器接收到這些用戶名/值對后，根據(jù)相應(yīng)的業(yè)務(wù)邏輯處理結(jié)果對用戶進行身份驗證。

通過對 FORM表單提交過程的分析，以及在工作中對大量文獻數(shù)據(jù)庫系統(tǒng)認(rèn)證過程的探索，已摸索出一種模擬FORM 表單自動認(rèn)證的方式，并已成功應(yīng)用于絕大多數(shù)主流文獻數(shù)據(jù)庫系統(tǒng)。目前文獻數(shù)據(jù)庫認(rèn)證系統(tǒng)流程設(shè)計、開發(fā)語言各不相同，但是只要是采用 FORM 表單方式均可以用相同的方法加以解決，即：首先以用戶登錄頁面為突破口，分析頁面源代碼程序，找出 FORM 表單代碼及表單最終提交的認(rèn)證頁面，將 FORM表單中與認(rèn)證無關(guān)的控件、按扭刪除，只保留認(rèn)證必需的表單元素，形成最簡化的 FORM 表單主體，并測試提交。其次將模擬 FORM表單集成到自有的文獻業(yè)務(wù)系統(tǒng)中，當(dāng)用戶成功登錄自有的文獻業(yè)務(wù)系統(tǒng)后，根據(jù)用戶名和權(quán)限從用戶信息表中讀取該用戶在文獻數(shù)據(jù)庫系統(tǒng)中的帳號和密碼，以及認(rèn)證URL，通過程序技術(shù)封裝到FORM表單，最后通過文獻業(yè)務(wù)系統(tǒng)向文獻數(shù)據(jù)庫發(fā)起提交，模擬用戶登錄，文獻數(shù)據(jù)庫將用戶所需的資源通過WEB方式反饋給用戶，從而完成自動認(rèn)證。

這種基于表單的自動認(rèn)證方式適用面廣，實現(xiàn)方法較為簡單，較容易與現(xiàn)有業(yè)務(wù)系統(tǒng)進行集成，但由于原理上基于對用戶認(rèn)證過程的模擬，所以對文獻數(shù)據(jù)庫系統(tǒng)的認(rèn)證頁面依賴性較強，如果認(rèn)證頁面內(nèi)容或地址等發(fā)生改變，將導(dǎo)致無法自動認(rèn)證。其次，這種自動認(rèn)證方式僅適用于基于 B/S 的Web 業(yè)務(wù)應(yīng)用系統(tǒng)，并且用戶認(rèn)證方式提供FORM表單認(rèn)證服務(wù)功能，對少數(shù)系統(tǒng)仍然無法實現(xiàn)。此外出于網(wǎng)絡(luò)信息安全方面的考慮，這種自動認(rèn)證方式比較適合應(yīng)用于VPN、網(wǎng)絡(luò)安全級別較高的局域網(wǎng)以及文獻數(shù)據(jù)庫鏡像系統(tǒng)環(huán)境下，但仍具有一定局限性，有待探索解決。

3 基于OPENAPI的自動認(rèn)證方式

OPENAPI是在互聯(lián)網(wǎng)上開放的應(yīng)用編程接口，基于超文本傳輸協(xié)議(HTTP)協(xié)議，以可擴展語言(XML)、JavaScript Object Notation等格式返回信息，在 WEB上構(gòu)建新的應(yīng)用，實現(xiàn)各異構(gòu)數(shù)據(jù)庫系統(tǒng)間的數(shù)據(jù)共享和互操作提供技術(shù)實現(xiàn)。目前，OPENAPI為文獻資源平臺各異構(gòu)系統(tǒng)間建立互操作，實現(xiàn)互通互聯(lián)提供了一個選擇，通過利用數(shù)據(jù)庫資源廠商提供的成熟的 OPENAPI，可以將對方的數(shù)據(jù)資源集成到自有的文獻業(yè)務(wù)系統(tǒng)中，與文獻業(yè)務(wù)系統(tǒng)的現(xiàn)有數(shù)字資源進行深度整合，向用戶提供更豐富的資源和更個性化的應(yīng)用。在此過程中，本文主要研究利用OPENAPI完成文獻數(shù)據(jù)庫系統(tǒng)的自動認(rèn)證，通過自動認(rèn)證與自有的文獻業(yè)務(wù)系統(tǒng)中的單點認(rèn)證(SSO)進行集成，實現(xiàn)用戶一次登錄便可以訪問包括OPENAPI集成的數(shù)據(jù)庫在內(nèi)的多種文獻資源。

3.1 典型的OPENAPI訪問權(quán)限控制分析

3.1.1 通過 IP地址或域名方式控制 OPENAPI(開放 API)訪問權(quán)限

對于遠(yuǎn)程登錄使用的數(shù)據(jù)庫資源，比如萬方數(shù)據(jù)、化工信息網(wǎng)等，其平臺管理功能中用戶管理會針對每個機構(gòu)用戶配置用戶提供的 IP地址范圍或者域名序列，當(dāng)用戶服務(wù)器或者安裝在用戶電腦上的客戶端發(fā)起開放 API訪問請求時，資源商平臺管理系統(tǒng)將在IP或域名列表中查找是否有與之匹配的IP地址或域名，通過檢驗的 IP地址或域名順利訪問資源，沒有通過驗證的則拒絕訪問。建立在訪問雙方相互信任基礎(chǔ)上的基于IP序列或域名訪問權(quán)限控制需要用戶具有相對固定的IP范圍和域名，可以通過 web服務(wù)器遠(yuǎn)程配置實現(xiàn)，操作簡便，常用 WEB服務(wù)器，如 Apache、微軟的 IIS等，都具有OPENAPI訪問權(quán)限控制功能。這種技術(shù)的缺點是作為網(wǎng)站級控制，實現(xiàn)精確控制有一定困難。高校圖書館和情報所及科研機構(gòu)的IP相對固定，所以采用開放API中IP限制的較多，比如清華大學(xué)、天津科技信息中心很多開放API都限制IP范圍內(nèi)使用。

3.1.2 授權(quán)方式控制OPENAPI訪問權(quán)限

為使用開放API的一方賦予一定許可權(quán)的訪問方式稱為授權(quán)方式，用戶作為被控制對象被賦予訪問許可。由于現(xiàn)實中控制需求多樣化，賦權(quán)和驗證、判斷方式的確定較復(fù)雜，有兩種使用率較高的開放API訪問權(quán)限控制：

3.1.2.1 OAuth

OAuth(Open Authorization)為用戶資源授權(quán)提供了一個安全、開放的標(biāo)準(zhǔn)，該標(biāo)準(zhǔn)以資源為中心，對于布局了多種托管文獻數(shù)據(jù)庫的文獻平臺而言，為不同用戶賦予不同資源數(shù)據(jù)庫使用權(quán)限，一般由資源擁有者為每個用戶進行單獨授權(quán)，這種方式要求授權(quán)和取消授權(quán)操作簡便。采用 Oauth可以避免授權(quán)后數(shù)據(jù)庫用戶修改密碼的麻煩。目前一些大型互聯(lián)網(wǎng)服務(wù)提供商，如Google、Amazon、微軟等均采用OAuth控制。OAuth對文獻數(shù)據(jù)庫控制各類數(shù)據(jù)庫資源方面具有重要價值，例如可以實現(xiàn)第三方賬號在文獻平臺登陸數(shù)據(jù)庫時的登錄。

3.1.2.2 API Key

API Key是開放API服務(wù)提供者為服務(wù)使用者發(fā)放的服務(wù)授權(quán)許可。API Key為了避免被盜號，往往采用數(shù)字和字符組合成字符串，當(dāng)程序請求 OPENAPI服務(wù)時，系統(tǒng)以參數(shù)方式把API Key傳遞給服務(wù)器。相對前面提及的方式，支持API Key授權(quán)方式的互聯(lián)網(wǎng)服務(wù)和內(nèi)容提供商更為普遍。由于API Key是靜態(tài)的，一旦泄露就會被盜用，所以根據(jù)不同需求，通常與 https加密傳輸、簽名驗證等組合使用；有的資源服務(wù)網(wǎng)站將使用 API Key的用戶網(wǎng)站域名與 API Key捆綁驗證。當(dāng) OPENAPI使用者較固定，內(nèi)容和服務(wù)提供者可以擁有授權(quán)權(quán)限，API Key是一個較好的選擇。目前一些文獻平臺已經(jīng)實現(xiàn)了對一些大型文獻數(shù)據(jù)庫資源的自動認(rèn)證，如讀秀、方正阿帕比，并集成到自有的文獻業(yè)務(wù)系統(tǒng)中。

3.2 OPENAPI認(rèn)證實例

方正阿帕比提供的單點登錄及認(rèn)證接口，采用 OPENAPI技術(shù)，提供給第三方客戶端開發(fā)人員，實現(xiàn)自動認(rèn)證的功能。該接口執(zhí)行登錄成功后，當(dāng)調(diào)用方正阿帕比所有子系統(tǒng)時無需再次登錄，若登錄失敗，則跳轉(zhuǎn)到相應(yīng)的錯誤頁面。用戶信息驗證采用的是用戶名+密碼+數(shù)字簽名，三者共同驗證，所有驗證信息均需驗證通過后方執(zhí)行單點登錄。

URL請求示例如下：

http：//xxx/xxx/?pid＝sso&uid＝testing1&pwd＝81DC 9BDB52D04DC20036DBD8313ED055&sign＝ MTIzNDU2&returnurl＝http：//xxxx.com&errorurl＝http：//xxxx.com/error. html&autoreg＝1&pdm＝1

調(diào)用接口API時的標(biāo)準(zhǔn)參數(shù)如表1所示：

表1 調(diào)用接口API的標(biāo)準(zhǔn)參數(shù)Tab.1 Standard parameters for API calling

簽名規(guī)則：

Sig簽名是將請求源串以及密鑰根據(jù)一定簽名方法生成的簽名值，用來提高傳輸過程參數(shù)的防篡改性。簽名值的生成共有 3個步驟：構(gòu)造源串、構(gòu)造密鑰和生成簽名值，具體通過用戶名、機構(gòu)標(biāo)識、時間戳等參數(shù)構(gòu)造原始字符串，之后對原始字符串進行DES加密，獲得有效的數(shù)字簽名。

在上述過程中可以與自有的文獻業(yè)務(wù)系統(tǒng)進行集成，根據(jù)需要，可將業(yè)務(wù)系統(tǒng)中用戶的 ID、密碼等參數(shù)傳入OPENAPI參數(shù)中，并通過HTTP方式將URL請求發(fā)送至方正阿帕比服務(wù)器端，實現(xiàn)業(yè)務(wù)系統(tǒng)授權(quán)用戶對方正阿帕比資源的自動認(rèn)證和訪問。

若用戶所有驗證信息均通過驗證，且登錄成功，則頁面跳轉(zhuǎn)到客戶端URL參數(shù)中return url指定的地址。若用戶驗證信息未通過，則跳轉(zhuǎn)到客戶端URL參數(shù)中指定的error url地址，并在該 url結(jié)尾添加錯誤碼。如 error url＝http：//xxxx/error. html，并跳轉(zhuǎn)至http：//xxxx/error.html?errorcode＝02，從而完成OPENAPI的全部認(rèn)證過程。

這種基于 OPENAPI的自動認(rèn)證方式對于互聯(lián)網(wǎng)應(yīng)用來說，最大的特點也是最大的優(yōu)點就是基于 HTTP協(xié)議開發(fā)成應(yīng)用開發(fā)的統(tǒng)一標(biāo)準(zhǔn)，對于使用的語言、采用的操作系統(tǒng)和應(yīng)用部署平臺都沒有太多的限制。與之類似的是 WebService采用XML作為數(shù)據(jù)傳輸承載，制定了解析標(biāo)準(zhǔn)為開發(fā)者異構(gòu)系統(tǒng)的信息交互帶來了可能，也成為至今為止應(yīng)用最廣泛的服務(wù)集成方式，通過WebService接口同樣可以完成用戶認(rèn)證、授權(quán)等多種管理功能。而隨著 Web 2.0的發(fā)展，RSS、Atom、JSON的大規(guī)模應(yīng)用，以及網(wǎng)絡(luò)開發(fā)門檻的降低，讓更多的網(wǎng)站加大了API技術(shù)開發(fā)投入的精力。

另外，由于認(rèn)證過程中采用了加密、簽名等安全技術(shù)，在保障用戶的隱私和安全性方面有了較大的提升?？梢杂行ПＵ系谌綉?yīng)用(這里指自有的文獻業(yè)務(wù)系統(tǒng))與資源數(shù)據(jù)庫開放平臺 API服務(wù)器之間通信的安全性，防止用戶帳戶信息盜用、數(shù)據(jù)篡改等惡意攻擊行為，因此在信息安全日趨重要的今天，可廣泛適用于互聯(lián)網(wǎng)復(fù)雜網(wǎng)絡(luò)環(huán)境下。但是，目前國內(nèi)提供商的服務(wù)成熟度以及安全等方面的措施，都僅僅是起步，特別是提供OPENAPI服務(wù)的文獻數(shù)據(jù)庫提供商還不普及，因此實現(xiàn)文獻資源的大規(guī)模集成條件還不成熟，今后還需要不斷的探索和發(fā)展。

4 結(jié) 語

隨著互聯(lián)網(wǎng)技術(shù)的快速發(fā)展，文獻數(shù)據(jù)庫系統(tǒng)作為 WEB應(yīng)用服務(wù)系統(tǒng)中的一種，自動身份認(rèn)證技術(shù)在其中得到了越來越普遍的應(yīng)用。本文通過對日常工作中幾種常用的自動認(rèn)證方式進行分析對比，得出其各自不同的認(rèn)證機制、優(yōu)勢、不足以及適用環(huán)境?？梢?，自動身份認(rèn)證在為用戶提供易用性的同時，也是實現(xiàn)科技文獻整合服務(wù)平臺數(shù)據(jù)庫單點認(rèn)證的基礎(chǔ)手段，相信隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，會有更多安全、易用、完善的自動認(rèn)證方式得到應(yīng)用。

［1］ 劉維紅，杭劍平. 聯(lián)合身份認(rèn)證及在校際資源網(wǎng)的應(yīng)用[J]. 信息安全與通信保密，2010(1)：126-129.

［2］ 賈西蘭，郭建峰. 圖書館行業(yè)OpenAPI利用的權(quán)限控制[J]. 圖書情報工作，2012(7)：21-25.

［3］ 翟曉娟，聶娜. 滿足用戶個體需求的圖書館開放平臺設(shè)計——基于OpenAPI、App、Mashup、SOA的集成實踐應(yīng)用[J]. 大學(xué)圖書館學(xué)報，2011，29(6)：26-33.

［4］ 黃書強，楊亞濤. 一種改進的基于 OpenID機制的網(wǎng)絡(luò)實名制方案設(shè)計[J]. 小型微型計算機系統(tǒng)，2012，33(6)：1228-1232.

［5］ 楊浩泉，皮冰鋒，彭酉，等. 基于 OpenID的可兼容身份認(rèn)證系統(tǒng)設(shè)計與實現(xiàn)[J]. 計算機應(yīng)用與軟件，2012，29(4)：281-284，292.

［6］ 何定華. 一種與應(yīng)用無關(guān)的 SSO系統(tǒng)設(shè)計與實現(xiàn)[J].科技通報，2012，28(4)：171-173.

［7］ 陳淥漪，管小清. 單點登錄(SSO)系統(tǒng)的設(shè)計與實現(xiàn)[J]. 微計算機信息，2008，24(27)：75-77.

［8］ 刁紅軍，朱曉旭，朱斐. 基于Web統(tǒng)一身份認(rèn)證服務(wù)的實現(xiàn)方案[J]. 計算機工程，2006(13)：277-279.

［9］ 邱小果. 編程實現(xiàn)基于Cookie驗證的HTTP請求的發(fā)送[J]. 微型機與應(yīng)用，2003(7)：35-37.

［10］ 周曉斌，許勇，張凌，等. 一種開放式 PKI身份認(rèn)證模型的研究[J]. 國防科技大學(xué)學(xué)報，2013，35(1)：169-174.

［11］ 龍毅宏，唐志紅，王亞龍，等. 面向 HTTP身份鑒別協(xié)議的單點登錄透明集成技術(shù)研究[J]. 計算機應(yīng)用研究，2013，30(9)：2813-2818.

［12］ 許方恒，陳暄，龍丹，等. 新型的多分布式用戶單點登錄模型[J]. 計算機應(yīng)用研究，2012，29(9)：3355-3357，3364.

［13］ 陳鵬，刁紅軍，朱斐，等. 一種基于Web單點登錄系統(tǒng)實現(xiàn)[J]. 計算機應(yīng)用與軟件，2007，24(11)：147-149，197.

Common Automatic Authentication Methods for Literature Database Systems

LI Jianhong
(Tianjin Zhonghuan Innovation Science & Technology Co.，Ltd.，Tianjin 300190，China)

In view of users’ demands on automatic authentication in DBMS，several frequently-used automatic authentication methods were compared. As a result，authentication mechanisms，advantages，shortages and applicable environments of these methods were concluded，which will offer convenience for users and provide reference for the literature resource integration.

literature database；automatic authentication；OPENAPI；certification API

TP311.131；G258.6

：A

：1006-8945(2015)02-0018-03

2015-01-09