單點登錄原理與技術實現比較

1.1    單點登錄原理與技術實現 比較

1.1 .1   單點登錄原理

單點登錄 （ SSO ） 是指一個用戶身份只需進行一次鑒權便可以訪問所有經授權的資源，而不需要多次認證。 SSO 機制能夠減少人為錯誤，同時提高整個系統的安全性。雖然 SSO 很有價值，但是它的實現并不容易，因為到目前為止還沒有一種用戶身份驗證的統一標準。 IBM WebSphere  Portal 服務器提供了各種手段使 SSO 的實現簡單化、安全化、有效化。

通常會有 外置代理和內置代理兩種方法。

1 ．外置代理

在有些情況下，可以使用一種類似中介的代理進程，該進程處于用戶和應用程序之間，如圖 1- 1 所示。當用戶被應用程序要求提供身份證明時，代理進程從用戶資料庫中得到用戶的信用狀，并送給應用程序。信用狀相當于一個令牌，它只有用戶的身份信息，而沒有用戶的密碼憑證。換句話說，使用外置代理實現單點登錄，被集成的 Web 應用系統是不再驗證該用戶在 Web 應用系統中的密碼的。它認為，只要你是 Portal 的合法用戶并且成功登錄了 Portal ，你只需告訴我你的身份跟角色，我就認為你是該 Web 系統中可以使用授權信息的合法用戶了。

圖 1- 1   門戶服務器進行身份驗證過程 — — Web 應用沒有提供 Authentication API 的情況

 ① 用戶登錄到門戶服務器，身份驗證服務對用戶進行身份驗證。

  ② 驗證通過，建立用戶信用狀，并請求建立用戶默認桌面。

  ③ 代 理程序使用用戶信用狀，并發送請求給目錄服務，要求得到 Web 應用的用戶名和口令。

  ④ 得到用戶名和權限信息。

  ⑤ 代理程序使用它們進入 Web 應用并依據權限信息得到應用數據。

  ⑥ 代理程序將得到的數據格式化后生成用戶默認桌面，應用程序的內容以門戶 Channel 的形式展現。

  ⑦ 將生成的桌面傳送給用戶。

上面的情況適用于 Web 應用沒有提供 Authentication API 的情況，對于提供 Authentication API 的 Web 應用（如 Lotus Notes ），則多出來一步，即第 4 步：鑒權。用戶在 Web 應用中的用戶名和密碼必須事先通過加密存儲機制存儲到 Portal 平臺，此時代理程序建立的信用狀同時包含了此用戶在該 Web 應用系統中的密碼。代理程序攜帶此用戶的用戶名和密碼調用 Web 驗證服務實現認證過程，認證完成后，至于此用戶在該 Web 系統中到底有哪些權限，這就由接下來的 Web 系統去執行了，因為此時此用戶已經通過調用驗證服務的手段成功登錄了該 Web 應用系統。如圖 1- 2 所示。

圖 1- 2   門戶服務器進行身份驗證過程 — — Web 應用提供 Authentication API 的情況

 ① 用戶登錄門戶服務器。

 ② 請求建立用戶默認桌面。

 ③ 代理程序使用 Portal Token 并批準使用 Web 應用的 Authentication API 進行用戶身份驗證。所使用的用戶名與登錄門戶服務器時使用的一樣，或者是一個映射值，映射表應存放在門戶服務器的 Profile 中。

 ④ 進行用戶鑒權。

 ⑤ 鑒權成功。

 ⑥ 代理程序使用 Web 應用 API   獲取數據。

 ⑦ 代理程序將得到的數據格式化后生成用戶默認桌面，應用程序的內容以門戶 Channel 的形式展現。

 ⑧ 將生成的桌面傳送給用戶。

上面所提到的代理程序，可以通過 IBM WebSphere Portal 提供的 API 編寫的  Servlet 程序實現。這個  Servlet   程序將用戶的信用狀傳遞給應用程序，并將用戶重定向到應用的主頁面。  

外置代理的優點：

—  啟動投資相對較少。

缺點：

—  不利于系統管理和維護。

—  對系統總體性能有影響。

—  不支持跨域的 SSO 。

2 ．內置代理

內置代理方法 是 指 利用策略管理軟件，即 Identity 服務器軟件。策略管理軟件的工作原理是，在 Web 服務器上安插一個代理模塊（ Agent Module ），該模塊與   Identity   服務器共同負責用戶身份驗證和授權信息。

要 將策略管理軟件與 Portal 服務器進行集成，可以將策略代理模塊安裝在內嵌于 Portal 服務器中的 Web 服務器上，并使用 Portal 服務器提供的 API ，基于策略管理軟件的 S ession 創建過程生成一個有效的 Portal   服務器 S ession 。這樣，用戶可以在策略管理系統的控制下訪問任何 W eb 應用。

內置代理的 優點：

—  通過 Identity 服務器及其 Web 代理模塊可以安全 、 有效地控制用戶身份驗證和資源訪問 。

—  提供集中的訪問控制管理，增強大型復雜應用系統的可管理性和效率 。

—  為系統開發人員提供一種簡單的方法對集中化的目錄資源進行訪問，易于擴展 。

—  通過 Extranet Web Agents ，可以無縫地集成 Web 應用 。

—  具有 支持百萬級用戶的良好系統擴展性 。

—  保護投資 。

—  支持跨域的 SSO 。

從邏輯概念上 看 ， Identity 服務器作為企業核心的應用訪問控制器，而 Portal 服務器則是一個內容聚合器，聚合由 Identity 服務器保護的應用。同時， Portal 服務器還作為企業內部安全的應用訪問轉送器。 使用內置代理實現 Portal 與 Web 應用系統的原理及過程如下，我們分 12 個步驟來介紹。

 ① 用戶訪問門戶網關。

 ② 門戶網關檢查當前 IPS Session 是否包含有效的 Cookie ，如果不包含（即 Session 還未建立），門戶網關則將信息包傳給門戶服務器的身份驗證模塊。

 ③ 服務器的身份驗證模塊將信息包轉發給 Identity 服務器的代理模塊。

 ④ 代理模塊給用戶發送一個經過定制的登錄頁面（此頁面顯示使用 Identity 服務器進行身份驗證）。

  ⑤ 用戶輸入用戶名 / 口令（或其他身份信息），并返回給代理模塊。

 ⑥ 代理模塊將該信息發送給 Identity   服務器。

 ⑦ Identity 服務器驗證用戶身份（查詢存儲用戶信息的目錄數據庫）。

 ⑧ 驗 證成功， Identity 服務器生成 Identity Cookie （包含驗證成功等信息） , 并發送給代理模塊。

 ⑨ 代理模塊存儲 Identity Cookie ，并調用門戶服務器的身份驗證模塊使 Session 有效（生成一個 Portal Session ）。

 ⑩ 門戶服務器的身份驗證模塊將 Identity Session 和 Portal Session 發送給用戶瀏覽器。

 ? 門戶網關保存 Portal Session ，使用戶的 Session 生效。

 ? 門戶網關給用戶發送門戶首頁。

一旦身份驗證流程完成，用戶不需要重新認證就可以訪問由門戶服務器及 Identity 服務器保護的任何資源和應用。

3 ． 頁面流方式實現單點登錄

頁面流方式的單點登錄，指的是用戶成功登錄 Portal 后，在業務系統中用戶每調用一次 Web 系統的頁面， Web 系統都要聯絡代理進行一次驗證。 iDSAME 產品就提供了這種功能，它是一種更加嚴格的訪問控制策略，用來保護企業核心、重要系統的數據和資源，具體實現是由 iDSAME 的 Web 代理以及相應的 URL 訪問策略來共同完成的。

Web 代理安裝在受保護資源的機器上，當用戶訪問受保護的系統資源時， Web 代理首先截獲請求，檢查訪問的是否是受保護資源，如果不是，則允許訪問；如果是， iDSAME 則會根據用戶的 Token 檢查用戶能訪問還是不能訪問。與內置代理、外置代理不同，使用該策略實現單點登錄會嚴重降低應用系統的性能，因為用戶每訪問一個頁面，都會引起一次鑒權的過程。通常，這種情況應用于企業的比較核心和重要的業務系統中。

4 ．交叉域單點登錄

交叉域單點登錄（ Cross Domain SSO ）是指實現單點登錄的幾個應用服務器在不同的域內。在這種情況下要實現單點登錄，必須將其他域轉換到本地域，進行域名映射。交叉域單點登錄實現原理示意圖如圖 1- 3 所示。

圖 1- 3   交叉域單點登錄實現原理示意圖

1.1 .2   單點登錄的技術方案

針對集成的不同的應用系統，我們會提供不同的單點登錄解決方案，下面是實現單點登錄功能的 常用技術方案。

1 ． LTPA （ Lightweight Third-Party Authentication ） 令牌環技術

LTPA 是一種令牌環，上面記錄了用戶的登錄信息和身份信息，它 提供 了 基于 Cookie 的輕量級第三方認證機制（ LTPA ），當用戶發出對資源的請求時，首先 必須 向 認證服務器 認證。認證成功后， 認證服務器 代表用戶生成 LTPA Cookie 。作為認證標記服務的 LTPA Cookie 中 包含用戶標識、密鑰和標記數據、緩沖區長度和到期信息，此信息使用 認證服務器 和 應用系統 之間共享的受密碼保護的密鑰加密。 認證服務器 在請求的 HTTP 頭中插入 Cookie ，該請求通過連接發送到 應用系統 ， 應用系統 服務器接收請求、解密 Cookie 并基于 Cookie 中提供的標識信息認證用戶。

2 ．基于表單的單點登錄（ Form-Based SSO ）

基 于表單的單點登錄 （ Form-Based SSO ） 功能 ， 允許 認證服務器 將已認證的用戶透明地登錄到需要通過 HTML 表單認證的后臺系統中 。基于表單的單點登錄實現原理示意圖如 圖 1- 4 所示。

圖 1- 4   基于表單的單點登錄實現原理示意圖

3 ． HTTP 頭文件（ HTTP Header ）技術

利用 HTTP Header 這種認證方式， 認證服務器 可以把經過認證的用戶身份信息（包括賬號、屬性信息等），通過 HTTP Header 傳給后臺的應用系統，后臺的應用系統可以從 HTTP Header 中把這些用戶信息截取出來，用來確認用戶身份，從而實現統一認證（單點登錄）的功能。這種統一認證的方式需要后臺的應用系統進行相應的修改，使它可以獲得 HTTP Header 中的用戶信息。

4 ．憑證保險庫（ GSO-Lockbox ）技術

GSO-Lockbox 這種實現單點登錄的方式一般會和 Form-Based SSO 方式一起來使用，主要 是 考慮到每個人在各個系統中的用戶身份可能會不一致，利用這種方式可以解決這種問題。利用 GSO-Lockbox ，可以建立起用戶身份信息和后臺應用系統之間的對應關系 。

在不同的產品中有各自的實現方式，例如，在 IBM WebSphere Portal 中叫做 Credential Vault ，也翻譯為 “憑證保險庫”。憑證保險庫為實現單點登錄的每套應用系統創建一個憑證保險段，在每個憑證保險段里則為每個 Web 用戶創建一個憑證保險槽。槽是最小的憑證單位，用來存儲一個用戶在一套應用系統中的用戶名和密碼鍵值對（見表 1- 1 ）。

表 1- 1   GSO-Lockbox 實現單點登錄的方式

以上幾種方式很難說誰最好，最佳實踐的做法是根據客戶的具體情況選用不同的解決方案，或幾種實現方案同時使用，依據不同的應用系統情況而定。但通常來說，應遵循如下幾個原則。

（ 1 ）對部署在 WebSphere Application Server 、 WebLogic Server 、 SAP NetWeaver Application Server 、 Domino 等服務器上能識別 LTPA 令牌環，且用戶目錄與 Portal 的用戶目錄為同一套，或者有一一對應關心的應用系統，與 Portal 實現單點登錄時，建議采用 LTPA 機制。

（ 2 ）對部署在 WebSphere Application Server 、 WebLogic Server 、 SAP NetWeaver Application Server 、 Domino 等服務器上，且用戶目錄與 Portal 的用戶目錄不是同一套，或者沒有一一對應的應用系統，與 Portal 實現單點登錄時，建議采用 JAAS 認證。

（ 3 ）用戶注冊表與 Portal 不一致，但應用系統中的用戶在 Portal 中都有對應的用戶時，不管其用戶名編排規則是否一致，皆建議采用憑證保險庫技術。

1.2    單點登錄在最佳項目實踐 中的應用

使用單點登錄技術實現 Portal 系統與其他應用系統的單點登錄后，用戶只要成功登錄 Portal ，就可以無須再次登錄而直接進入應用系統，或者在 Portal 中直接使用應用系統中授權的應用或信息。在進行實際項目開發時，通常會設計如下幾種模式，作為單點登錄及單點登錄的擴展應用。

1.2 .1   以列表的方式進入應用系統首頁

以列表的方式進入應用系統首頁，指的是提供一個展現應用系統列表的 Portlet ，上面列出了實現單點登錄的所有應用系統（見圖 1- 5 ）。點擊列表中的條目，可以直接在新的頁面中進入該應用系統，而無須再次登錄或者提供任何憑證。

圖 1- 5   以列表 Portlet 的方式應用單點登錄

1.2 .2   直接進入各個應用系統的深度集成模式

很多時候，用戶需要進入到系統的某個深層次頁面，而不是從系統首頁一步步點擊。單點登錄的深度集成模式指的是通過不同的標簽直接進入到客戶想進去的頁面，如圖 1- 6 所示。

圖 1- 6   點擊不同的標簽直接進入到應用系統的深度集成頁面

1.2 .3   以應用導航的方式梳理后集成

很多客戶會有這樣的經驗：當應用系統過多時，自己都忘記了發起某個業務或某個功能的頁面到底在哪套系統中。應用導航集成思路指的是，不是從應用系統的角度梳理深度集成的頁面，而是從用戶的業務應用角度來分析，將用戶經常使用的功能頁面從業務的角度梳理、分類，并分門別類地展現到系統中。用戶只需知道要干什么就行了，而不必關心要執行的這個頁面到底在哪套系統中。也就是說，讓用戶忘掉系統的存在。圖 1- 7 所示是典型的應用導航圖。

圖 1- 7   典型的應用導航圖（應用導航允許用戶忘記系統的存在，只需知道要干什么就行了）

1.2 .4   作為統一待辦調用任務處理界面時的通用驗證邏輯單元

單點登錄的最廣泛和深入的應用莫過于統一工作待辦了。把所有系統中每個用戶需要待辦的事項分門別類地按照業務域劃分出來，并集中展現到一個個欄目中，讓用戶原來需要登錄多套系統去處理的待辦事項，在一個欄目中就完成了，多方便啊！圖 1- 8 所示是將來自幾十套系統的待辦事項統一集成到一個欄目中，并按照 9 大業務域劃分的一個典型場景。

圖 1- 8   按照業務域在一個欄目中集中展現來自幾十套系統的待辦事項

1.3    單點登錄技術的開發 /配置指南

單點登錄的實現技術還有很多，比如 JAAS 認證等，但在項目實踐中應用最多的就是 LTPA 令牌環和憑證保險庫技術。本節詳細介紹這兩種方案的開發 / 配置過程。

1.3 .1  LTPA 技術是如何實現

1.3 .1.1　 LTPA 對于 SSO 的 工作 機制

LTPA 機制適用于部署在 WebSphere Application Server 、 WebLogic Server 、 SAP NetWeaver Application Server 、 Domino 等服務器上，它能識別 LTPA 令牌環，以及用戶目錄與 Portal 的用戶目錄為同一套，或有一一對應關系的應用系統。本節以 WebSphere Portal 與 Domino 之間實現單點登錄為例，介紹 LTPA 機制是如何配置的。

LTPA （ 輕量級第三方認證 ）是一個令牌環， 它是通過使用 Domain Cookie 而啟用的。這種經過加密的會話 C ookie 被放置在用戶瀏覽器中，包含了一些信息， WebSphere 或者 Domino Application 服務器可以加密這些信息，并使用這些信息來說明用戶已經通過該 C ookie 所覆蓋的 DNS （ Domain Naming Service ，域名服務）域中的認證。

LTPA C ookie 包含以下信息 。

—  Cookie 名稱：總是設置為 LtpaToken 。

—  域：設置為 Internet 域，該域由參與單點登錄的所有服務器共享（例如： mycompany.   com ）。

—  Cookie 到期：設置為當瀏覽器終止時刪除該 C ookie 。

—  安全：設置為開狀態，以強制使用安全套接字層 （ SSL ） 。 LTPA 配置有一個設置參數，使它創建只通過 SSL 發送的 C ookie 。

—  Cookie 值：被設置為 LTPA 標記。

LTPA 標記是一個加密的字符串，它包含以下信息 。

—  用戶數據：一般被設置為用戶 ID ，但也可以是任何用于 唯 一標識用戶的用戶信息。

—  過期時間：與 Cookie 過期不同，這個字段用于強加一個時間限制，時間限制從登錄進來的那一刻算起，而不受瀏覽器活動或者不活動影響。 這個時間限制是一個可 設 置的 LTPA 配 置， 在默認 情況下為 30 分鐘。

1.3 .1.2   如何配置 Portal 與 Domino 之間的 SSO

Portal 與 Domino 的 SSO 可以通過配置 LTPA 的方法來實現。通俗地講就是，用戶登錄 Portal 系統后， Portal 系統會把用戶登錄信息加密成 LTPA 并存放到某一位置，當用戶繼續訪問 Domino 系統中的授權資源時， Domino 系統會自動讀取該位置的 LTPA ，讀到并解密后拿到 Domino 系統中驗證，如果驗證通過，則顯示給用戶授權信息。所以要配置 Portal 與 Domino 之間的 SSO 非常容易，只要先將 Domino 系統服務器的 LTPA 導出并存為 .key 文件，然后導入 Portal 系統所在的服務器（ WebShpere Application Server ）中就可以了。

1.3 .2   憑證保險庫 技術是如何實現的

1.3 .2.1   概述

WebSphere Portal 提供了 Credential Vault （憑證保險庫）功能 ， Credential Vault 通過 Basic Authentication Header 將用戶名和密碼傳遞給后端應用程序。為了使 Domino 服務器接受通過這個頭部傳遞進來的憑證，必須將服務器會話驗證配置為 Single-Server 模式。在 Multi-Server 模式中，該服務器只接受通過 LTPA 機制傳遞的憑證。因此，為了與 Domino 應用程序一起使用用于 SSO 的 Credential Vault ，必須將 Domino 服務器會話驗證配置為 Single-Server 模式。

要使用 Credential Vault ，用戶需輸入一些憑證，輸入一次就夠了。隨后，這些憑證被存放在一個經過加密的數據庫表中，每當用戶訪問該 P ortlet 時，這些憑證便被傳遞給后端應用程序。要了解關于配置 Credential Vault 的細節， 請 參見 WebSphere Portal InfoCenter 。

1.3 .2.2 　憑證保險庫實現 SSO 原理

下面以一個最簡單的 SSO 過程為例進行介紹。

  普 通業務系統的登錄過程：系統首先提供一個頁面，讓我們輸入應用程序中的用戶信息。

  用戶輸入用戶名和密碼后，單擊 “登錄”按鈕，該頁面提交到 form 所對應的 Action （ check_login.jsp ）進行處理，我們看 check_login.jsp 的代碼。

接下來提交到數據庫驗證用戶信息的合法性，如果合法，則定位到授權信息頁面；否則，重定位回到登錄頁面 login.jsp 。

在 Portlet 開發中是如何解決這個問題的？

其實起關鍵作用的還是 check_login.jsp 頁面，它需要獲得用戶名和密碼兩個鍵值，然后拿著這兩個參數到后臺數據庫去驗證。在常規的登錄方式中，這兩個參數是通過 login.jsp 獲得的。事實上，只要 Portlet 能為該頁面提供這兩個鍵值，也就實現了登錄的自動化。而 Portlet 要得到這兩個參數是非常簡單的，所以實現單點登錄也就非常簡單了。我們可以復制一個 check_login.jsp 文件，例如名為 check_portal_login.jsp ，這個頁面的兩個參數是 Portlet 提供的，剩下的事完全交給業務系統去處理，頁面流轉和全線控制都不用我們管了。

1.3 .2.3 　開發 Portlet 實現 SSO 的方法

（ 1 ） JSP 取值傳送 URL

我們開發一個使用系統專用槽的 Portlet ，使用憑證保險庫的相關接口在 PortletView.jsp 中取出用戶存儲在憑證保險庫中的鍵值，然后以 URL 的方式傳送到 iFrame 內。

PortletView.jsp 的部分代碼如下：

如果用戶已經在憑證保險庫中存儲了鍵值，那么該 Portlet 的 View.jsp 頁面被初始化時， iFrame 中將顯示用戶成功登錄后的授權信息，也就是實現了 SSO 。

（ 2 ） Class 取值寫 Session ， JSP 取出并以 URL 傳送

我們在 Portlet 的控制類中取得用戶存儲在憑證保險庫中的鍵值對，并在 PortletView 的 doview() 方法中寫入 Session 。在 Portlet 的Ｖ iwe.jsp 中取出 Session ，然后像第一種方法一樣，以 URL 的方式傳送到目的代理。

（ 3 ） Class 寫 Session ，單點登錄代理取 Session

我們在 Portlet 的控制類中取得用戶存儲在憑證保險庫中的鍵值對，并在 PortletView 的 doview() 方法中寫入 Session 。而專為 Portal 開發的協助登錄頁面則會直接從 Session 中取出用戶憑證，具體的操作方法略過。

由于這幾種方法開發起來比較簡單，所以這里就一帶而過，不再詳細介紹了。