光纖工程中基于OpenID的統一認證系統設計與實現

胡共由，胡捷程，凌力

0 引言

隨著云計算的應用與普及，單點登錄(single sign-on,SSO)越來越為人們所需求，也成為了信息化和網絡擴展的必然要求。單點登錄，即用戶在一個登陸點進行身份驗證后，可以借此對一組與之相關的網絡應用服務進行訪問，而不必在一個個依次去登錄各自的用戶認證。OpenID 協議便是以此為目的誕生的網絡服務認證協議，用戶將URI 作為用戶標識，OpenID 身份提供商作為驗證方(OpenID provider,OP)，網絡應用服務提供商作為依賴方(Relying Party,RP)，只需進行一次登錄驗證，無需重復注冊和登錄認證便可請求任何依賴此OP的網絡應用服務，其開放、自由、離散的標準化機制使之成為了炙手可熱的單點登錄和數據共享方面的應用協議。現代化的企業，無論是大型企業還是中小型企業，都迫切需要在單點登錄與用戶認證方面有長足的改善，以適應新的企業管理系統在RFID 技術與云計算技術的大熱潮中與時俱進，從根本上保證安全性并提高運營效率。

本文從一個光線工程管理項目入手，設計并實現了一個在企業運作中能夠普遍適用的基于OpenID的統一認證系統，對實際應用中的分等級認證、多重身份登錄、用戶角色授權等諸多問題提出了可行的解決方案，為云計算中企業用戶的統一認證提供參考。

1 OpenID 機制

OpenID 是一種廣泛應用于云計算中的去中心化身份認證技術。OpenID 以統一的身份標識(如URI 等)作為唯一識別的用戶身份標記，用戶可以隨意的選擇一個OpenID 服務網站或者自行建立一個提供這樣服務的網站，只要完成一次注冊，每個用戶所對應的唯一的URI 將通過一定程序編程生成唯一的認證標識，口令則被安全的存儲在一個OpenID 服務器中，用戶請求某個RP的應用服務時RP 會向該OP 進行用戶合法性認證，因此用戶無需進行多次注冊便可請求各個RP的應用服務。OpenID 身份驗證由OP 完成，支持該OP的RP 通過OpenID 協議委托OP 來實現用戶身份信息的確認，OpenID 賬戶信息在互聯網范圍內是共享的并存放在數據云中。下面簡要介紹OpenID 認證過程，OpenID協議流程操作步驟為，如圖1所示：

圖1：OpenID 流程

1)終端用戶訪問OP 進行用戶注冊。

2)注冊成功返回注冊信息。

3)用戶提交詳細個人資料，并可在注冊OP的數據空間進行個性化配置。

4)用戶提交應用站點服務請求。

5)應用站點返還給用戶一個其支持的OpenID 登錄頁面。

6)用戶進行OpenID 認證。

7)RP 向OP 請求身份認證。

8)引導到用戶登錄界面。

9)登錄。

10)完成認證。

11)用戶相當于用RP的注冊帳號成功進行登錄。

同傳統的兩種認證機制獨立驗證和私有第三方驗證相比較而言，OpenID 認證機制很好的解決了用戶標識的唯一性問題，使得用戶跳出了重復注冊、多次輸入密碼等一系列的重復操作，大大減輕了用戶的認證負擔，經過近些年的快速發展，OpenID 技術標準日趨成熟，其簡單、開放、共享、便捷的特性使得在各種領域都用廣大的應用空間，對于如何開發出更具有商業應用價值的認證模型成為了很多人關心的問題。

2 光纖工程系統簡介

光纖工程是為了光纖監測和系統維護，基于物聯網和云計算而建立的光纖管理系統，用于對光纖進行線路施工、工程維護等工作，實現智能化、可維護、易考核的高效工程管理系統，并與光纖監測系統協同工作，形成完善的一體化系統。系統工作流程，如下圖所示：

圖2：光纖工程系統

光纖工程工作流程可分為3 類：

1)初始準備階段。施工人員為機房、機架和光纖打上RFID 標簽。

2)工程實施階段。工程師設計程序并生成智能工單，施工人員下載工單并依次對光纖進行連接工作。

3)維護工作階段。光纖的修復、更換、改接、拆除等操作。

在本項目中，按人員職能可分為項目管理員、工程設計師和施工人員，項目管理員對某個具體項目進行物流和人事管理，工程設計師負責對項目進行軟件編程和程序設計，施工人員則執行工程實施工作。

3 基于OpenID 統一身份認證

現在諸如像中國移動等公司的光纖管理基本就是外包給一些專門用來提供光纖管理服務的公司進行操作，那么在這些外包公司中工作人員用各自的ID 登錄到系統站點時所擁有的權限必然是不一樣的，有的人可能還擁有多重身份，比如A 在同X 公司的合作項目中既是工程設計師又是施工人員，他的ID 登錄到提供應用服務的站點時應該如何去區別他的身份并授予相應權限？而既然是專門提供光纖管理服務的公司，其同時與多家企業進行項目合作時需要設置一個統一認證，這樣項目中的工作人員只要用同一個賬戶登錄便可訪問企業對于各個合作公司的數據空間和應用站點，這樣既可以減輕員工的操作負擔同時也保證了工作效率。對此，我們將OpenID 應用到該系統中，設計并實現了一個用于對其用戶進行統一身份認證的模型。

3.1 系統結構

作為是向工作人員所提供的統一認證，那么其登錄形式要盡可能的多樣化，滿足用戶可以在公司、工地甚至在家里都可以用手機、平板電腦、筆記本電腦、臺式機等等終端進行登錄，同時我們自行建立一臺OP 服務器并將所有用戶數據保存在本地的后臺數據庫中，具體系統結構，如圖3所示：

圖3：基于OpenID 統一認證系統結構

用戶可使用手機、PAD、PC 等進行登錄，在公司內部可用WiFi 連接到OP 服務器，這樣既快捷又可以保證數據安全性，而在施工地點或者其他非公司網絡覆蓋的區域可以用GSM、3G、互聯網登錄，OP 服務器和數據庫都由公司自己提供，項目中我們用一臺安裝有Apache的服務器作為OP，并用SQL server 2008r2 作為后臺數據庫保存OpenID用戶數據，OP 通過互聯網與各個合作公司的RP 站點進行用戶認證工作，本系統的統一認證主要實現分等級認證、多重身份登錄、用戶角色授權等功能的設計，下文逐一進行介紹。

3.2 分級認證

對于用戶而言，同一個ID 應該可以具有不同的操作權限因為有時候過多的操作權限不僅沒有必要，反而會影響數據安全性。比如項目管理員會習慣性的每天登錄帳號查看各項目進度，那么這里系統只需賦予他的ID 閱讀權限即可，如果他的ID 和口令被人截取那也只有閱讀權限這樣會降低損失，而當他回到公司有一個較為安全的網絡環境時，那么他想對工程實施計劃進行修改等操作時便可以用更高的權限進行登錄，系統賦予他的ID 修改、刪除、插入等權限。這樣因不同場合和工作需求來進行分級登錄認證在光纖工程中是完全有必要的，于是我們對用戶登錄進行了以下三類等級認證的設置。

1.匿名認證。有區別于一些網站上游客登錄的性質，匿名認證驗證了登錄ID的合法性，具體的操作，如圖4所示：

圖4：匿名認證和用戶認證

用戶對RP 站點1 請求匿名認證時，OP 只需要返回給RP 一個隨機碼來表明該用戶擁有此登錄ID，說明已經通過認證，但僅僅是通過認證而用戶沒有任何的閱讀、插入、刪除等具體操作權限，當然系統可以添加顯示一些比如該ID所擁有的權限等級等比較基本的信息。匿名登錄最大的作用在于任何一個用戶都可以用來驗證自己擁有的ID 是否合法，項目管理員、工程設計師和施工人員都可以用此方法來查看自己ID 在其他合作公司RP 站點的合法性，以及查看自己在系統中的權限等級，而系統同樣可以統計登錄次數方便RP 站點依此進行統計分析。

2.用戶認證。相比于匿名認證，用戶認證則是在認證用戶ID 合法性的基礎上對用戶ID的權限進行了識別和授權，這里主要是指用戶ID 擁有閱讀權限。具體操作如圖4所示，當用戶就RP 站點2 請求用戶認證時，OP 將登錄用戶的ID提供給RP，RP 可以根據此唯一標識為用戶提供閱讀權限級別的網絡服務。于是項目管理員可以查看項目總體進度和項目實施計劃，工程設計師可以查看施工進度，施工人員可以查看自己負責區域的施工情況等等。這種情況下OP 必須得向RP 提供用戶ID 以及其他可用信息，RP 依此來對用戶提供網絡服務。

3.內容認證。 相比于用戶認證，內容認證加入了從用戶到RP的數據交互，這種認證不僅要識別用戶ID的合法性，又要對用戶進行高級別權限的授權，同時還要保證用戶向所RP 提交數據的完整性、可靠性、安全性，防止RP 對數據進行修改，我們對協議進行如下改進，如圖5所示：

圖5：內容認證

用戶端將消息t 做公鑰加密c=E(k,t)發送到OP 服務器，其中用戶和RP 擁有私鑰可以進行解密，OP 將密文c 同用戶身份i 做私鑰加密T=Ek(c,i)并將T 發送給RP，這樣任何用戶可以在OP 查詢到T，用戶將密文c 發送給RP，RP 擁有密鑰并解密得消息t 進行發布，任何有相關管理權限的用戶在知道了是由哪個用戶修改了數據的情況下，只需查詢并解密OP 中的T 即可判斷RP 發布的消息t 是否被篡改，篡改與否直接影響RP的信用度，過低的信用度無疑會失去公司企業對該站點的信任。在實際應用中，項目管理員A 若想修改項目實施計劃，他用ID 進行內容登錄并進行修改操作，同時作為合作公司的管理員B 對項目計劃進行查看時，在知道了是由A 修改了計劃的情況下，可以在OP 中找到T，解密即可判斷RP 發布的數據是否被第三方惡意修改。

對于用戶來說采用相對較低的認證等級進行登錄可以放心的進行各種操作，比如工程設計師進行匿名登錄查看自己ID的合法性和擁有權限等級，那么他不必過于擔心自己的個人信息等會被截取和泄漏，而采用相對較高的認證等級進行登錄時則要注意登錄環境的安全性，比如在網吧或者其他信息不安全的場所不要進行登錄。在OpenID 中RP 對用戶服務的不同定位決定了同一個ID 可能擁有不同的操作權限，而越高的權限意味著越高的安全要求和風險，那么在用戶身份認證中加入用戶分級認證是合理而且必須的，通過項目我們也驗證了其在實際應用中的可行性和實效性。

3.3 多重身份

對于光纖工程中的工作人員而言可能同時兼任著不同的職位，在不同的職業場合要進行不同的工作，比如C 既是工程設計師又是工程施工人員，有時候要進行系統和程序的設計工作有時候又要去工地進行工程實施，進入一家合作企業站點時是項目管理員進入另一家合作企業的站點時是程序設計師，那么他的ID 登錄時必然要有多種的身份識別，于是同一ID的多重身份認證在企業統一認證平臺中是必不可少的。

當同一ID 在不同服務網站擁有多重身份和權限時，再用原來的OpenID 進行身份認證以及請求網絡服務時會遇到問題。我們舉例來說明：工程設計師H 擔任同B 公司合作中項目經理一職，H 在B 公司的云服務站點注冊且擁有自己的賬戶Y，同時B 公司授予權限，假設他使用OpenID 身份X 登錄到B的服務器，那么此時他擁有B 站點中對某些數據進行閱讀、修改等權限，但這是他在B 服務器中的數據空間是OpenID 身份X 對應的操作權限而不是他最初注冊到B 站點時的賬戶Y的數據空間，因此他無法打開Y的賬戶管理頁面、操作記錄、個人資料、最新通知等等數據，如果他忘記了Y的登錄信息和密碼那么他將無法找回Y的數據資源，這一定程度會影響用戶的判斷和操作，更會對用戶更新自己賬戶信息帶來極大的不便。

為了解決這一問題，我們在原有的基礎上對協議進行一定改進，如圖6所示：

圖6：多重身份認證

操作步驟為：

1.終端用戶申請RP 網絡服務。

2.RP 請求身份認證。

3.用戶通過OpenID 進行登錄認證。

4.OP 將用戶標志性信息發送給RP。

5.RP通過比較注冊用戶與OP發送過來用戶資料的相似度得出此用戶合法并將信息發送給OP。

6.RP 同用戶進行一個挑戰響應。

7.挑戰響應通過，通知OP。

8.用戶登錄RP，權限和數據空間同在RP 注冊的帳號完全一致。

由于是企業云服務統一認證，用戶在注冊的時候會比一般性的RP 站點要嚴謹的多，單位、職業、用戶名、注冊郵箱、聯系電話等信息組合在一起幾乎可以形成一個唯一化的用戶身份，同樣在OpenID 服務器中在用戶注冊時會保存以上幾種甚至更多的用戶個性信息，同一個用戶在不同的站點注冊時的身份信息應該有高度的相似性，通過OpenID 服務器與RP 站點的用戶信息做比較就可以得出是否是當前登錄用戶。按OpenID 協議，用戶、OP 以及RP 之間擁有足夠的信任度，用戶信息詳細保存在OP 和RP 上，當用戶通過OP登錄某個RP 時OP 將用戶特征性的詳細信息發送給RP，RP 比較用戶信息相似度，當相似度達到某個閾值，在本項目中滿足單位、職業、用戶名、注冊郵箱相同，且其余信息80%相同時，RP 發送個用戶一個挑戰響應，向用戶提問用其注冊時的安全問題，若用戶通過此挑戰響應則系統判定用戶身份登錄有效，OP 服務器登錄到實際的RP 賬戶中。如果以上認證失敗則按照原來的OpenID 協議，用戶只能登錄OP 服務器賬戶。回到剛才的登錄問題中，如果執行改進后的協議，工程師H 用OP 服務器登錄B 站點，只要是合法身份，他在OP 和站點B的用戶信息肯定符合系統判定閾值，只要通過系統挑戰響應便可登錄到站點B的注冊賬戶Y 中去，大大減輕了用戶操作負擔并使得用戶在云服務站點之間來回登錄轉換身份提供了有效的解決辦法。

3.4 角色授權

角色是本系統中的核心要素，當用戶登錄時并不是登錄ID 獲得了權限而是用戶ID 放入到了某個角色中獲得了該角色所擁有的權限。系統管理員可以按照企業的各自要求定義擁有不同權限的角色，甚至可以具體到單個數據的權限，這使得授權非常靈活和多樣。本項目中的角色定義，如圖7所示：

圖7：角色定義

光纖工程外包公司定義了A、B、C3 種角色，角色A擁有對員工信息、項目計劃進行查詢和修改的權限，同時可以查看項目進度，角色B 擁有制作、查詢、修改所有工單的權限，角色C 擁有對工單3 和其進度進行查詢的權限。各員工ID 進行登錄時的操作，如圖8所示：

圖8：用戶角色授權

本項目中各工作人員職能定位為：項目管理員擁有對其負責項目的所有數據進行修改的權限，工程設計師有對項目工單進行添加、修改和刪除權限，施工人員只有對自身工作進行查詢的權限。那么只要在數據庫定義3 類角色，角色A擁有項目最高權限，包括對所有數據的操作，角色B 擁有對所有工單數據操作權限，角色C 擁有對工作內容的閱讀權限。這樣，當上述3 種職位的人用各自ID 登錄時，OP會根據系統判定對ID 進行識別并分別將項目管理員、工程設計師、施工人員的ID 添加到角色A、角色B、角色C 中，這3 種職業便擁有了各自應該具備的操作權限，當然這種操作權限不僅僅局限于本公司站點，因為是基于OpenID的統一認證登錄，那么在其他依賴此OP的RP 應用站點也擁有相應的角色與之對應，這里不一一說明了。而當此項目完成，公司間的合作結束而需要收回訪問RP 站點的權限時只需要刪除數據庫中的角色A、B、C 即可。

通過定義角色來授予用戶權限是基于OpenID 統一認證系統中減輕授權工作量的有效手段，比如有10 個項目管理員、50 個工程設計師、500 個施工人員，如果按照傳統的用戶授權方式需要對這560 個用戶一一進行配置，而且如果其中的權限發生變更重新配置會非常麻煩，而用角色授權的方法只需要定義如上3 種角色A、B、C 便一次性解決了授權問題，不僅減少了管理強度也降低了多次的重復工作而引起的誤操作。

4 總結

由于云計算以及SaaS 模式等技術的日漸火熱，統一認證的重要性再一次被驗證，本文從一個光纖工程項目入手，提出了企業共享數據云并提供云服務的設想，重點設計了基于OpenID 協議的統一身份認證系統，通過對比傳統的認證方式發現了基于OpenID 協議認證方式的優勢與不足，同時在一定層度上予以了改進，可以說是為云計算發展到企業云服務的創新性研究。該系統經光纖工程項目驗證，可以有效提高用戶操作效率并確保數據安全性，用戶可以因環境信息安全性的差異選擇合適認證等級進行登錄，同一用戶又可以以多重身份進行認證，系統則按照定義角色來配置登錄用戶的操作權限，減輕了用戶和系統的操作負擔、提高了項目管理的運轉效率，是企業云服務中有效的統一認證系統。

畢竟云服務還沒有非常的成熟，在企業方面的實際應用還不十分廣泛，我們將在已有的基礎上繼續圍繞云計算、SaaS 模式、RFID 技術等熱門技術對企業統一認證平臺進行進一步的分析、設計與實現，將統一認證和數據安全上升到單個應用服務中去，為企業云服務的實際應用提供有效參考。

[1]岳小均.基于云計算的統一身份認證與管理平臺研究與實現[D].電子科技大學碩士論文,2011.

[2]李馥娟.單點登錄技術分析及在數字圖書館中的應用[J].圖書情報工作,2009(21):111.

[3]楊浩泉,皮冰鋒,彭酋,楊華,鄒綱,王主龍.基于OpenID的可兼容身份認證系統設計與實現[J].計算機應用與軟件,2012,29(4):281-284,292.

[4]David Recordon,Drummond Reed.OpenID 2.0:a platform for user-centric identity management.[J]ACM,Nov,2006.

[5]Yoshisato Takeda,Seiichi Kondo,Yasuhide Kitayama,Massashi Torato,Tsuyoshi Motegi.Avoidance fo performance bottlenecks caused by HTTP redirect in identity management protocols.[J]ACM,Nov,2006.