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

1.1.1  單點登入原理

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

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

1．外接代理

在有些情況下，可以使用一種類似中介的代理程序，該程序處於使用者和應用程式之間，如圖1-1所示。當用戶被應用程式要求提供×××明時，代理程序從使用者資料庫中得到使用者的信用狀，並送給應用程式。信用狀相當於一個令牌，它只有使用者的身份資訊，而沒有使用者的密碼憑證。換句話說，使用外接代理實現單點登入，被整合的

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

 ①使用者登入到門戶伺服器，身份驗證服務對使用者進行身份驗證。

 ②驗證通過，建立使用者信用狀，並請求建立使用者預設桌面。

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

 ④

 ⑤代理程式使用它們進入Web應用並依據許可權資訊得到應用資料。

 ⑥代理程式將得到的資料格式化後生成使用者預設桌面，應用程式的內容以門戶Channel的形式展現。

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

上面的情況適用於Web應用沒有提供Authentication API的情況，對於提供Authentication API 的Web應用（如Lotus Notes），則多出來一步，即第4步：鑑權。使用者在Web應用中的使用者名稱和密碼必須事先通過加密儲存機制儲存到Portal平臺，此時代理程式建立的信用狀同時包含了此使用者在該Web

圖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，基於策略管理軟體的Session建立過程生成一個有效的 Portal 伺服器 Session。這樣，使用者可以在策略管理系統的控制下訪問任何Web應用。

內建代理的優點：

— 通過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而啟用的。這種經過加密的會話Cookie被放置在使用者瀏覽器中，包含了一些資訊，WebSphere或者Domino Application 伺服器可以加密這些資訊，並使用這些資訊來說明使用者已經通過該Cookie所覆蓋的DNS（Domain Naming Service，域名服務）域中的認證。

LTPA Cookie 包含以下資訊。

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

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

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

— 安全：設定為開狀態，以強制使用安全套接字層（SSL）。LTPA配置有一個設定引數，使它建立只通過SSL傳送的Cookie。

— 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，使用者需輸入一些憑證，輸入一次就夠了。隨後，這些憑證被存放在一個經過加密的資料庫表中，每當使用者訪問該Portlet時，這些憑證便被傳遞給後端應用程式。要了解關於配置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中取出使用者憑證，具體的操作方法略過。

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