引言
除非一項服務僅提供匿名訪問，否則它就需要對用戶進行管理。為了分析和實現用戶體驗的個性化，服務需要確定每個連接用戶的身份。因此，對用戶身份的管理非常重要。但是，許多傳統的應用都在彼此隔絕地解決身份認證問題，從而導致了用戶管理存儲及系統的數量激增。這種各自為戰的身份管理方法會產生如下一些問題：
1）用戶必須記住和手動重新輸入各種各樣數目繁多的賬戶和憑據。
2）這種給用戶帶來的額外負擔往往會導致用戶使用弱口令或在不同安全域中重復使用相同的憑據。因此，數據的敏感性可能就會受到損害。
3）用戶可能在另外創建賬戶時會躊躇不前，這就會導致網站訪問者的注冊率和轉化率都很低。
4）應用提供商需要重新設計并管理一個身份管理系統。這要涉及相當多的工作，而這一領域往往并不是Web開發人員的核心競爭力所在。
5）各自為戰的方式會失去在經過用戶授權后可以充分利用一些共同的網站需求和共享所獲得的信息的機會。
為解決這一問題，人們曾經嘗試了各種各樣的方法，比如目錄同步、實時查找等。這些方法雖然解決了一些問題，但又制造出另外一些問題。因此，必須引入新的身份管理方法，其中聯合身份管理就是目前眾多企業所采取的身份管理方案，它能夠處理多個單位、大量應用并支持數千甚至數百萬用戶公共身份的管理。盡管其需要一系列復雜的技術和業務流程，但目的卻很簡單：跨越管理邊界，自動共享身份信息。
1 身份管理的通用架構
身份管理是一個集中式的、自動的方法，提供雇員或者其他授權的個人對資源擁有企業范圍的訪問。其重點是為用戶定義一個身份，為該身份關聯屬性，并完成用戶的身份認證。圖1 即為通用的身份管理架構。
圖1 通用的身份管理架構
圖中說明了通用身份管理結構中的實體和數據流。一個當事人就是一個身份持有者，也就是一個想要訪問網絡資源和服務的人，用戶設施、代理程序和服務器系統都可能作為當事人。當事人向身份提供者證明自己，身份提供者為當事人關聯認證信息，如屬性等。
數據消費者是一些實體，能夠得到并使用由身份和屬性提供者提供的數據，數據消費者常被用于支持授權決定和收集審計信息，如數據庫服務器或者文件服務器，需要客戶的證書來決定為該客戶提供什么樣的訪問權限。
2 聯合身份管理的通用架構
在本質上，身份聯合是身份管理在多個安全域上的一個擴展，這些域包括自治的內部商業單元、外部的商業伙伴以及其他第三方的應用和服務。目的是提供數字身份共享，使得用戶只需要一次認證就可以訪問多個域的應用和資源。這些域是相對自治或者獨立的，因此可以采用非集中化控制，當然，合作的組織之間必須形成一個基于協商和相互信任的標準來安全地共享數字身份。圖2 給出了通用聯合身份管理結構中的實體和數據流。
圖2 聯合身份管理架構
其中具體的數據流為：
①終端用戶的瀏覽器或其他應用需要和同一個域的身份提供者“通話”，終端用戶也提供與身份關聯的屬性值；
②一些與身份關聯的屬性，如許可的角色，可能由同一個域的管理員提供；
③用戶想要訪問的服務提供者的其他域，從資源域的身份提供者處獲取身份信息，認證信息和關聯信息；
④服務提供者和遠程用戶會話，執行基于用戶身份和屬性的訪問控制限制。
身份提供者通過和用戶以及管理者會話、協議交換來獲得屬性信息，身份管理使得用戶一次性提供這些信息并將其保存，在滿足授權和隱私策略時發布給數據消費者。而服務提供者是一些實體，能夠得到和使用由身份和屬性提供者維持和提供的數據，數據消費者常被用于支持授權決定和收集審計信息。一個服務提供者可以和用戶以及身份提供者在同一個域，但聯合身份管理中服務提供者和用戶在不同的域。
3 聯合身份管理的標準
目前涉及聯合身份管理的標準主要有兩大系列。在消費者市場中，開放式認證系統（OpenID，Open Identification）很流行；而在企業市場上，較為普通的是使用安全斷言標記語言（SAML，SecurityAssertion Markup Language）。
3.1 OpenID
OpenID 是一個對于以用戶為中心的數字身份的開放式、分散的自由框架。它消除了跨越不同站點的多個用戶名的需求，簡化了用戶的在線體驗。也就是說，它提供了一種可使用某一家服務提供商來建立賬戶并向其他接受OpenID 身份驗證的網站提供登錄功能的框架。即它是一個聯合式身份認證系統，可用于跨不同Web服務的用戶身份驗證工作。用戶可以使用OpenID 身份認證提供商網站上的憑據，登錄到OpenID 依賴方的網站上。圖3 顯示了利用谷歌應用程序（Google Apps）的Web 應用的過程。在這種情況下，Web 應用是依賴方，而Google是身份認證提供商。
其中的數據流為：①用戶要在一個OpenID 身份提供商處創建一個賬戶；②用戶訪問一個OpenID依賴方的網站；③該網站提供了多種登錄選項，其中包括指向OpenID 身份認證提供商的鏈接。依賴方將用戶指向身份認證提供商，進行身份認證；④用戶使用身份認證提供商來驗證自己的身份；⑤身份認證提供商向依賴方提供一個令牌，以此來確認用戶的身份；⑥用戶現在無需再次輸入密碼就可以訪問依賴方的網站了。
圖3 Google登錄認證
3.2 SAML
SAML 是一種基于可擴展標記語言（XML，eXrensible Markup Language）的標準，用于在安全域之間，也就是在身份提供商與服務提供商之間交換認證及授權數據。它與OpenID 類似，也允許服務提供商僅提供服務而無須自己實現一個身份驗證系統。相反，該服務提供商會委托身份認證提供商來驗證用戶的身份。
SAML 是一個抽象的框架，它規定了斷言的定義以及用于獲取和傳輸這些斷言的協議。最重要的是，SAML 的核心規范并沒有定義任何最終用戶可見的行為。
對于那些需要與顧客身份存儲相連接的GoogleApps 托管服務，托管在Google 上的應用就是依賴方，但客戶要負責提供一個基于SAML 的用戶認證服務，因此它就是身份認證提供商。圖4 為對GoogleApps 進行SAML 驗證的過程，其步驟如下述。
圖4 對Google Apps進行SAML驗證
①在開始進行身份驗證之前，合作伙伴首先要向Google 提供其單點登錄（SSO，Single Sign-On）服務的統一資源定位符（URL，Uniform ResourceLocator），還要提供一個公鑰，Google 要使用它來對SAML相應進行驗證；
②當用戶請求訪問一個托管的Google 時，就會開始一個這樣的認證過程；
③Google 會產生一個SAML 身份驗證請求。然后，Google 就會將用戶瀏覽器重定向到身份認證提供商那里，在該SSO 服務的URL 中，嵌入有SAML 請求和所請求的Google 應用的URL；
④身份認證提供商會對該SAML請求進行解碼，然后再驗證用戶的身份驗證。在驗證用戶身份時，可以要求用戶提供一個有效的登錄系統，也可以通過檢查有效的會話Cookie 來進行驗證；
⑤身份認證提供商生成一個SAML 響應，其中包含驗證用戶的用戶名。這一響應使用非對稱加密算法的公鑰和私鑰進行了數字簽名。身份認證提供商會對SAML響應進行編碼，然后將其返回到用戶瀏覽器，同時還帶有對瀏覽器的重定向指令；
⑥瀏覽器將此消息轉發給Google 的斷言消費者服務（ACS，Assertion Consumer Service）；⑦Google 的ACS 會使用驗證提供商的公共密鑰來對SAML響應進行校驗。如果驗證成功，ACS 就會將用戶重定向到目標URL中，并登錄到Google Apps的賬戶上。
總之，這兩個標準很相似。SAML 較為靈活，但實施起來也較難。OpenID迎合了Web SSO 的需要，它定義了一種專門的用戶交互方式。如果你的目標是基于Web 的單點登錄，那么OpenID 就是最簡單的一種解決方案了。在其他情況下，比如在使用后端身份存儲進行透明身份驗證的情況下，則SAML能夠提供更多的選擇。
4 結語
集成的身份管理是云計算所面臨的最大挑戰之一。目前最佳的解決方案是不要建立自己的身份管理解決方案，而是積極采用聯合式身份識別解決方案，要使用OpenID 或SAML 來利用別人的身份存儲，這樣就可以使得企業能夠更好地進行日志記錄和審計工作，同時還能降低與密碼重置和安全訪問現有的異構應用相關的成本[7]。同樣，它們還能減少孤兒賬戶的風險，從而防止那些已離開公司的前雇員們訪問應用。它們用一個全面的關于訪問權限的視圖來取代了那些基于電子表格的報表機制，這一視圖能夠讓你清楚地了解安全態勢，并能幫助你實現集中式的、全企業范圍的安全控制。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://m.hanmeixuan.com/
本文標題：云計算環境下聯合身份管理研究
相關文章
