單點(diǎn)登錄原理與技術(shù)實(shí)現(xiàn)比較

1.1    單點(diǎn)登錄原理與技術(shù)實(shí)現(xiàn) 比較

1.1 .1   單點(diǎn)登錄原理

單點(diǎn)登錄 （ SSO ） 是指一個(gè)用戶身份只需進(jìn)行一次鑒權(quán)便可以訪問(wèn)所有經(jīng)授權(quán)的資源，而不需要多次認(rèn)證。 SSO 機(jī)制能夠減少人為錯(cuò)誤，同時(shí)提高整個(gè)系統(tǒng)的安全性。雖然 SSO 很有價(jià)值，但是它的實(shí)現(xiàn)并不容易，因?yàn)榈侥壳盀橹惯€沒有一種用戶身份驗(yàn)證的統(tǒng)一標(biāo)準(zhǔn)。 IBM WebSphere  Portal 服務(wù)器提供了各種手段使 SSO 的實(shí)現(xiàn)簡(jiǎn)單化、安全化、有效化。

通常會(huì)有 外置代理和內(nèi)置代理兩種方法。

1 ．外置代理

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

圖 1- 1   門戶服務(wù)器進(jìn)行身份驗(yàn)證過(guò)程 — — Web 應(yīng)用沒有提供 Authentication API 的情況

 ① 用戶登錄到門戶服務(wù)器，身份驗(yàn)證服務(wù)對(duì)用戶進(jìn)行身份驗(yàn)證。

  ② 驗(yàn)證通過(guò)，建立用戶信用狀，并請(qǐng)求建立用戶默認(rèn)桌面。

  ③ 代 理程序使用用戶信用狀，并發(fā)送請(qǐng)求給目錄服務(wù)，要求得到 Web 應(yīng)用的用戶名和口令。

  ④ 得到用戶名和權(quán)限信息。

  ⑤ 代理程序使用它們進(jìn)入 Web 應(yīng)用并依據(jù)權(quán)限信息得到應(yīng)用數(shù)據(jù)。

  ⑥ 代理程序?qū)⒌玫降臄?shù)據(jù)格式化后生成用戶默認(rèn)桌面，應(yīng)用程序的內(nèi)容以門戶 Channel 的形式展現(xiàn)。

  ⑦ 將生成的桌面?zhèn)魉徒o用戶。

上面的情況適用于 Web 應(yīng)用沒有提供 Authentication API 的情況，對(duì)于提供 Authentication API 的 Web 應(yīng)用（如 Lotus Notes ），則多出來(lái)一步，即第 4 步：鑒權(quán)。用戶在 Web 應(yīng)用中的用戶名和密碼必須事先通過(guò)加密存儲(chǔ)機(jī)制存儲(chǔ)到 Portal 平臺(tái)，此時(shí)代理程序建立的信用狀同時(shí)包含了此用戶在該 Web 應(yīng)用系統(tǒng)中的密碼。代理程序攜帶此用戶的用戶名和密碼調(diào)用 Web 驗(yàn)證服務(wù)實(shí)現(xiàn)認(rèn)證過(guò)程，認(rèn)證完成后，至于此用戶在該 Web 系統(tǒng)中到底有哪些權(quán)限，這就由接下來(lái)的 Web 系統(tǒng)去執(zhí)行了，因?yàn)榇藭r(shí)此用戶已經(jīng)通過(guò)調(diào)用驗(yàn)證服務(wù)的手段成功登錄了該 Web 應(yīng)用系統(tǒng)。如圖 1- 2 所示。

圖 1- 2   門戶服務(wù)器進(jìn)行身份驗(yàn)證過(guò)程 — — Web 應(yīng)用提供 Authentication API 的情況

 ① 用戶登錄門戶服務(wù)器。

 ② 請(qǐng)求建立用戶默認(rèn)桌面。

 ③ 代理程序使用 Portal Token 并批準(zhǔn)使用 Web 應(yīng)用的 Authentication API 進(jìn)行用戶身份驗(yàn)證。所使用的用戶名與登錄門戶服務(wù)器時(shí)使用的一樣，或者是一個(gè)映射值，映射表應(yīng)存放在門戶服務(wù)器的 Profile 中。

 ④ 進(jìn)行用戶鑒權(quán)。

 ⑤ 鑒權(quán)成功。

 ⑥ 代理程序使用 Web 應(yīng)用 API   獲取數(shù)據(jù)。

 ⑦ 代理程序?qū)⒌玫降臄?shù)據(jù)格式化后生成用戶默認(rèn)桌面，應(yīng)用程序的內(nèi)容以門戶 Channel 的形式展現(xiàn)。

 ⑧ 將生成的桌面?zhèn)魉徒o用戶。

上面所提到的代理程序，可以通過(guò) IBM WebSphere Portal 提供的 API 編寫的  Servlet 程序?qū)崿F(xiàn)。這個(gè)  Servlet   程序?qū)⒂脩舻男庞脿顐鬟f給應(yīng)用程序，并將用戶重定向到應(yīng)用的主頁(yè)面。  

外置代理的優(yōu)點(diǎn)：

—  啟動(dòng)投資相對(duì)較少。

缺點(diǎn)：

—  不利于系統(tǒng)管理和維護(hù)。

—  對(duì)系統(tǒng)總體性能有影響。

—  不支持跨域的 SSO 。

2 ．內(nèi)置代理

內(nèi)置代理方法 是 指 利用策略管理軟件，即 Identity 服務(wù)器軟件。策略管理軟件的工作原理是，在 Web 服務(wù)器上安插一個(gè)代理模塊（ Agent Module ），該模塊與   Identity   服務(wù)器共同負(fù)責(zé)用戶身份驗(yàn)證和授權(quán)信息。

要 將策略管理軟件與 Portal 服務(wù)器進(jìn)行集成，可以將策略代理模塊安裝在內(nèi)嵌于 Portal 服務(wù)器中的 Web 服務(wù)器上，并使用 Portal 服務(wù)器提供的 API ，基于策略管理軟件的 S ession 創(chuàng)建過(guò)程生成一個(gè)有效的 Portal   服務(wù)器 S ession 。這樣，用戶可以在策略管理系統(tǒng)的控制下訪問(wèn)任何 W eb 應(yīng)用。

內(nèi)置代理的 優(yōu)點(diǎn)：

—  通過(guò) Identity 服務(wù)器及其 Web 代理模塊可以安全 、 有效地控制用戶身份驗(yàn)證和資源訪問(wèn) 。

—  提供集中的訪問(wèn)控制管理，增強(qiáng)大型復(fù)雜應(yīng)用系統(tǒng)的可管理性和效率 。

—  為系統(tǒng)開發(fā)人員提供一種簡(jiǎn)單的方法對(duì)集中化的目錄資源進(jìn)行訪問(wèn)，易于擴(kuò)展 。

—  通過(guò) Extranet Web Agents ，可以無(wú)縫地集成 Web 應(yīng)用 。

—  具有 支持百萬(wàn)級(jí)用戶的良好系統(tǒng)擴(kuò)展性 。

—  保護(hù)投資 。

—  支持跨域的 SSO 。

從邏輯概念上 看 ， Identity 服務(wù)器作為企業(yè)核心的應(yīng)用訪問(wèn)控制器，而 Portal 服務(wù)器則是一個(gè)內(nèi)容聚合器，聚合由 Identity 服務(wù)器保護(hù)的應(yīng)用。同時(shí)， Portal 服務(wù)器還作為企業(yè)內(nèi)部安全的應(yīng)用訪問(wèn)轉(zhuǎn)送器。 使用內(nèi)置代理實(shí)現(xiàn) Portal 與 Web 應(yīng)用系統(tǒng)的原理及過(guò)程如下，我們分 12 個(gè)步驟來(lái)介紹。

 ① 用戶訪問(wèn)門戶網(wǎng)關(guān)。

 ② 門戶網(wǎng)關(guān)檢查當(dāng)前 IPS Session 是否包含有效的 Cookie ，如果不包含（即 Session 還未建立），門戶網(wǎng)關(guān)則將信息包傳給門戶服務(wù)器的身份驗(yàn)證模塊。

 ③ 服務(wù)器的身份驗(yàn)證模塊將信息包轉(zhuǎn)發(fā)給 Identity 服務(wù)器的代理模塊。

 ④ 代理模塊給用戶發(fā)送一個(gè)經(jīng)過(guò)定制的登錄頁(yè)面（此頁(yè)面顯示使用 Identity 服務(wù)器進(jìn)行身份驗(yàn)證）。

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

 ⑥ 代理模塊將該信息發(fā)送給 Identity   服務(wù)器。

 ⑦ Identity 服務(wù)器驗(yàn)證用戶身份（查詢存儲(chǔ)用戶信息的目錄數(shù)據(jù)庫(kù)）。

 ⑧ 驗(yàn) 證成功， Identity 服務(wù)器生成 Identity Cookie （包含驗(yàn)證成功等信息） , 并發(fā)送給代理模塊。

 ⑨ 代理模塊存儲(chǔ) Identity Cookie ，并調(diào)用門戶服務(wù)器的身份驗(yàn)證模塊使 Session 有效（生成一個(gè) Portal Session ）。

 ⑩ 門戶服務(wù)器的身份驗(yàn)證模塊將 Identity Session 和 Portal Session 發(fā)送給用戶瀏覽器。

 ? 門戶網(wǎng)關(guān)保存 Portal Session ，使用戶的 Session 生效。

 ? 門戶網(wǎng)關(guān)給用戶發(fā)送門戶首頁(yè)。

一旦身份驗(yàn)證流程完成，用戶不需要重新認(rèn)證就可以訪問(wèn)由門戶服務(wù)器及 Identity 服務(wù)器保護(hù)的任何資源和應(yīng)用。

3 ． 頁(yè)面流方式實(shí)現(xiàn)單點(diǎn)登錄

頁(yè)面流方式的單點(diǎn)登錄，指的是用戶成功登錄 Portal 后，在業(yè)務(wù)系統(tǒng)中用戶每調(diào)用一次 Web 系統(tǒng)的頁(yè)面， Web 系統(tǒng)都要聯(lián)絡(luò)代理進(jìn)行一次驗(yàn)證。 iDSAME 產(chǎn)品就提供了這種功能，它是一種更加嚴(yán)格的訪問(wèn)控制策略，用來(lái)保護(hù)企業(yè)核心、重要系統(tǒng)的數(shù)據(jù)和資源，具體實(shí)現(xiàn)是由 iDSAME 的 Web 代理以及相應(yīng)的 URL 訪問(wèn)策略來(lái)共同完成的。

Web 代理安裝在受保護(hù)資源的機(jī)器上，當(dāng)用戶訪問(wèn)受保護(hù)的系統(tǒng)資源時(shí)， Web 代理首先截獲請(qǐng)求，檢查訪問(wèn)的是否是受保護(hù)資源，如果不是，則允許訪問(wèn)；如果是， iDSAME 則會(huì)根據(jù)用戶的 Token 檢查用戶能訪問(wèn)還是不能訪問(wèn)。與內(nèi)置代理、外置代理不同，使用該策略實(shí)現(xiàn)單點(diǎn)登錄會(huì)嚴(yán)重降低應(yīng)用系統(tǒng)的性能，因?yàn)橛脩裘吭L問(wèn)一個(gè)頁(yè)面，都會(huì)引起一次鑒權(quán)的過(guò)程。通常，這種情況應(yīng)用于企業(yè)的比較核心和重要的業(yè)務(wù)系統(tǒng)中。

4 ．交叉域單點(diǎn)登錄

交叉域單點(diǎn)登錄（ Cross Domain SSO ）是指實(shí)現(xiàn)單點(diǎn)登錄的幾個(gè)應(yīng)用服務(wù)器在不同的域內(nèi)。在這種情況下要實(shí)現(xiàn)單點(diǎn)登錄，必須將其他域轉(zhuǎn)換到本地域，進(jìn)行域名映射。交叉域單點(diǎn)登錄實(shí)現(xiàn)原理示意圖如圖 1- 3 所示。

圖 1- 3   交叉域單點(diǎn)登錄實(shí)現(xiàn)原理示意圖

1.1 .2   單點(diǎn)登錄的技術(shù)方案

針對(duì)集成的不同的應(yīng)用系統(tǒng)，我們會(huì)提供不同的單點(diǎn)登錄解決方案，下面是實(shí)現(xiàn)單點(diǎn)登錄功能的 常用技術(shù)方案。

1 ． LTPA （ Lightweight Third-Party Authentication ） 令牌環(huán)技術(shù)

LTPA 是一種令牌環(huán)，上面記錄了用戶的登錄信息和身份信息，它 提供 了 基于 Cookie 的輕量級(jí)第三方認(rèn)證機(jī)制（ LTPA ），當(dāng)用戶發(fā)出對(duì)資源的請(qǐng)求時(shí)，首先 必須 向 認(rèn)證服務(wù)器 認(rèn)證。認(rèn)證成功后， 認(rèn)證服務(wù)器 代表用戶生成 LTPA Cookie 。作為認(rèn)證標(biāo)記服務(wù)的 LTPA Cookie 中 包含用戶標(biāo)識(shí)、密鑰和標(biāo)記數(shù)據(jù)、緩沖區(qū)長(zhǎng)度和到期信息，此信息使用 認(rèn)證服務(wù)器 和 應(yīng)用系統(tǒng) 之間共享的受密碼保護(hù)的密鑰加密。 認(rèn)證服務(wù)器 在請(qǐng)求的 HTTP 頭中插入 Cookie ，該請(qǐng)求通過(guò)連接發(fā)送到 應(yīng)用系統(tǒng) ， 應(yīng)用系統(tǒng) 服務(wù)器接收請(qǐng)求、解密 Cookie 并基于 Cookie 中提供的標(biāo)識(shí)信息認(rèn)證用戶。

2 ．基于表單的單點(diǎn)登錄（ Form-Based SSO ）

基 于表單的單點(diǎn)登錄 （ Form-Based SSO ） 功能 ， 允許 認(rèn)證服務(wù)器 將已認(rèn)證的用戶透明地登錄到需要通過(guò) HTML 表單認(rèn)證的后臺(tái)系統(tǒng)中 ?；诒韱蔚膯吸c(diǎn)登錄實(shí)現(xiàn)原理示意圖如 圖 1- 4 所示。

圖 1- 4   基于表單的單點(diǎn)登錄實(shí)現(xiàn)原理示意圖

3 ． HTTP 頭文件（ HTTP Header ）技術(shù)

利用 HTTP Header 這種認(rèn)證方式， 認(rèn)證服務(wù)器 可以把經(jīng)過(guò)認(rèn)證的用戶身份信息（包括賬號(hào)、屬性信息等），通過(guò) HTTP Header 傳給后臺(tái)的應(yīng)用系統(tǒng)，后臺(tái)的應(yīng)用系統(tǒng)可以從 HTTP Header 中把這些用戶信息截取出來(lái)，用來(lái)確認(rèn)用戶身份，從而實(shí)現(xiàn)統(tǒng)一認(rèn)證（單點(diǎn)登錄）的功能。這種統(tǒng)一認(rèn)證的方式需要后臺(tái)的應(yīng)用系統(tǒng)進(jìn)行相應(yīng)的修改，使它可以獲得 HTTP Header 中的用戶信息。

4 ．憑證保險(xiǎn)庫(kù)（ GSO-Lockbox ）技術(shù)

GSO-Lockbox 這種實(shí)現(xiàn)單點(diǎn)登錄的方式一般會(huì)和 Form-Based SSO 方式一起來(lái)使用，主要 是 考慮到每個(gè)人在各個(gè)系統(tǒng)中的用戶身份可能會(huì)不一致，利用這種方式可以解決這種問(wèn)題。利用 GSO-Lockbox ，可以建立起用戶身份信息和后臺(tái)應(yīng)用系統(tǒng)之間的對(duì)應(yīng)關(guān)系 。

在不同的產(chǎn)品中有各自的實(shí)現(xiàn)方式，例如，在 IBM WebSphere Portal 中叫做 Credential Vault ，也翻譯為 “憑證保險(xiǎn)庫(kù)”。憑證保險(xiǎn)庫(kù)為實(shí)現(xiàn)單點(diǎn)登錄的每套應(yīng)用系統(tǒng)創(chuàng)建一個(gè)憑證保險(xiǎn)段，在每個(gè)憑證保險(xiǎn)段里則為每個(gè) Web 用戶創(chuàng)建一個(gè)憑證保險(xiǎn)槽。槽是最小的憑證單位，用來(lái)存儲(chǔ)一個(gè)用戶在一套應(yīng)用系統(tǒng)中的用戶名和密碼鍵值對(duì)（見表 1- 1 ）。

表 1- 1   GSO-Lockbox 實(shí)現(xiàn)單點(diǎn)登錄的方式

以上幾種方式很難說(shuō)誰(shuí)最好，最佳實(shí)踐的做法是根據(jù)客戶的具體情況選用不同的解決方案，或幾種實(shí)現(xiàn)方案同時(shí)使用，依據(jù)不同的應(yīng)用系統(tǒng)情況而定。但通常來(lái)說(shuō)，應(yīng)遵循如下幾個(gè)原則。

（ 1 ）對(duì)部署在 WebSphere Application Server 、 WebLogic Server 、 SAP NetWeaver Application Server 、 Domino 等服務(wù)器上能識(shí)別 LTPA 令牌環(huán)，且用戶目錄與 Portal 的用戶目錄為同一套，或者有一一對(duì)應(yīng)關(guān)心的應(yīng)用系統(tǒng)，與 Portal 實(shí)現(xiàn)單點(diǎn)登錄時(shí)，建議采用 LTPA 機(jī)制。

（ 2 ）對(duì)部署在 WebSphere Application Server 、 WebLogic Server 、 SAP NetWeaver Application Server 、 Domino 等服務(wù)器上，且用戶目錄與 Portal 的用戶目錄不是同一套，或者沒有一一對(duì)應(yīng)的應(yīng)用系統(tǒng)，與 Portal 實(shí)現(xiàn)單點(diǎn)登錄時(shí)，建議采用 JAAS 認(rèn)證。

（ 3 ）用戶注冊(cè)表與 Portal 不一致，但應(yīng)用系統(tǒng)中的用戶在 Portal 中都有對(duì)應(yīng)的用戶時(shí)，不管其用戶名編排規(guī)則是否一致，皆建議采用憑證保險(xiǎn)庫(kù)技術(shù)。

1.2    單點(diǎn)登錄在最佳項(xiàng)目實(shí)踐 中的應(yīng)用

使用單點(diǎn)登錄技術(shù)實(shí)現(xiàn) Portal 系統(tǒng)與其他應(yīng)用系統(tǒng)的單點(diǎn)登錄后，用戶只要成功登錄 Portal ，就可以無(wú)須再次登錄而直接進(jìn)入應(yīng)用系統(tǒng)，或者在 Portal 中直接使用應(yīng)用系統(tǒng)中授權(quán)的應(yīng)用或信息。在進(jìn)行實(shí)際項(xiàng)目開發(fā)時(shí)，通常會(huì)設(shè)計(jì)如下幾種模式，作為單點(diǎn)登錄及單點(diǎn)登錄的擴(kuò)展應(yīng)用。

1.2 .1   以列表的方式進(jìn)入應(yīng)用系統(tǒng)首頁(yè)

以列表的方式進(jìn)入應(yīng)用系統(tǒng)首頁(yè)，指的是提供一個(gè)展現(xiàn)應(yīng)用系統(tǒng)列表的 Portlet ，上面列出了實(shí)現(xiàn)單點(diǎn)登錄的所有應(yīng)用系統(tǒng)（見圖 1- 5 ）。點(diǎn)擊列表中的條目，可以直接在新的頁(yè)面中進(jìn)入該應(yīng)用系統(tǒng)，而無(wú)須再次登錄或者提供任何憑證。

圖 1- 5   以列表 Portlet 的方式應(yīng)用單點(diǎn)登錄

1.2 .2   直接進(jìn)入各個(gè)應(yīng)用系統(tǒng)的深度集成模式

很多時(shí)候，用戶需要進(jìn)入到系統(tǒng)的某個(gè)深層次頁(yè)面，而不是從系統(tǒng)首頁(yè)一步步點(diǎn)擊。單點(diǎn)登錄的深度集成模式指的是通過(guò)不同的標(biāo)簽直接進(jìn)入到客戶想進(jìn)去的頁(yè)面，如圖 1- 6 所示。

圖 1- 6   點(diǎn)擊不同的標(biāo)簽直接進(jìn)入到應(yīng)用系統(tǒng)的深度集成頁(yè)面

1.2 .3   以應(yīng)用導(dǎo)航的方式梳理后集成

很多客戶會(huì)有這樣的經(jīng)驗(yàn)：當(dāng)應(yīng)用系統(tǒng)過(guò)多時(shí)，自己都忘記了發(fā)起某個(gè)業(yè)務(wù)或某個(gè)功能的頁(yè)面到底在哪套系統(tǒng)中。應(yīng)用導(dǎo)航集成思路指的是，不是從應(yīng)用系統(tǒng)的角度梳理深度集成的頁(yè)面，而是從用戶的業(yè)務(wù)應(yīng)用角度來(lái)分析，將用戶經(jīng)常使用的功能頁(yè)面從業(yè)務(wù)的角度梳理、分類，并分門別類地展現(xiàn)到系統(tǒng)中。用戶只需知道要干什么就行了，而不必關(guān)心要執(zhí)行的這個(gè)頁(yè)面到底在哪套系統(tǒng)中。也就是說(shuō)，讓用戶忘掉系統(tǒng)的存在。圖 1- 7 所示是典型的應(yīng)用導(dǎo)航圖。

圖 1- 7   典型的應(yīng)用導(dǎo)航圖（應(yīng)用導(dǎo)航允許用戶忘記系統(tǒng)的存在，只需知道要干什么就行了）

1.2 .4   作為統(tǒng)一待辦調(diào)用任務(wù)處理界面時(shí)的通用驗(yàn)證邏輯單元

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

圖 1- 8   按照業(yè)務(wù)域在一個(gè)欄目中集中展現(xiàn)來(lái)自幾十套系統(tǒng)的待辦事項(xiàng)

1.3    單點(diǎn)登錄技術(shù)的開發(fā) /配置指南

單點(diǎn)登錄的實(shí)現(xiàn)技術(shù)還有很多，比如 JAAS 認(rèn)證等，但在項(xiàng)目實(shí)踐中應(yīng)用最多的就是 LTPA 令牌環(huán)和憑證保險(xiǎn)庫(kù)技術(shù)。本節(jié)詳細(xì)介紹這兩種方案的開發(fā) / 配置過(guò)程。

1.3 .1  LTPA 技術(shù)是如何實(shí)現(xiàn)

1.3 .1.1　 LTPA 對(duì)于 SSO 的 工作 機(jī)制

LTPA 機(jī)制適用于部署在 WebSphere Application Server 、 WebLogic Server 、 SAP NetWeaver Application Server 、 Domino 等服務(wù)器上，它能識(shí)別 LTPA 令牌環(huán)，以及用戶目錄與 Portal 的用戶目錄為同一套，或有一一對(duì)應(yīng)關(guān)系的應(yīng)用系統(tǒng)。本節(jié)以 WebSphere Portal 與 Domino 之間實(shí)現(xiàn)單點(diǎn)登錄為例，介紹 LTPA 機(jī)制是如何配置的。

LTPA （ 輕量級(jí)第三方認(rèn)證 ）是一個(gè)令牌環(huán)， 它是通過(guò)使用 Domain Cookie 而啟用的。這種經(jīng)過(guò)加密的會(huì)話 C ookie 被放置在用戶瀏覽器中，包含了一些信息， WebSphere 或者 Domino Application 服務(wù)器可以加密這些信息，并使用這些信息來(lái)說(shuō)明用戶已經(jīng)通過(guò)該 C ookie 所覆蓋的 DNS （ Domain Naming Service ，域名服務(wù)）域中的認(rèn)證。

LTPA C ookie 包含以下信息 。

—  Cookie 名稱：總是設(shè)置為 LtpaToken 。

—  域：設(shè)置為 Internet 域，該域由參與單點(diǎn)登錄的所有服務(wù)器共享（例如： mycompany.   com ）。

—  Cookie 到期：設(shè)置為當(dāng)瀏覽器終止時(shí)刪除該 C ookie 。

—  安全：設(shè)置為開狀態(tài)，以強(qiáng)制使用安全套接字層 （ SSL ） 。 LTPA 配置有一個(gè)設(shè)置參數(shù)，使它創(chuàng)建只通過(guò) SSL 發(fā)送的 C ookie 。

—  Cookie 值：被設(shè)置為 LTPA 標(biāo)記。

LTPA 標(biāo)記是一個(gè)加密的字符串，它包含以下信息 。

—  用戶數(shù)據(jù)：一般被設(shè)置為用戶 ID ，但也可以是任何用于 唯 一標(biāo)識(shí)用戶的用戶信息。

—  過(guò)期時(shí)間：與 Cookie 過(guò)期不同，這個(gè)字段用于強(qiáng)加一個(gè)時(shí)間限制，時(shí)間限制從登錄進(jìn)來(lái)的那一刻算起，而不受瀏覽器活動(dòng)或者不活動(dòng)影響。 這個(gè)時(shí)間限制是一個(gè)可 設(shè) 置的 LTPA 配 置， 在默認(rèn) 情況下為 30 分鐘。

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

Portal 與 Domino 的 SSO 可以通過(guò)配置 LTPA 的方法來(lái)實(shí)現(xiàn)。通俗地講就是，用戶登錄 Portal 系統(tǒng)后， Portal 系統(tǒng)會(huì)把用戶登錄信息加密成 LTPA 并存放到某一位置，當(dāng)用戶繼續(xù)訪問(wèn) Domino 系統(tǒng)中的授權(quán)資源時(shí)， Domino 系統(tǒng)會(huì)自動(dòng)讀取該位置的 LTPA ，讀到并解密后拿到 Domino 系統(tǒng)中驗(yàn)證，如果驗(yàn)證通過(guò)，則顯示給用戶授權(quán)信息。所以要配置 Portal 與 Domino 之間的 SSO 非常容易，只要先將 Domino 系統(tǒng)服務(wù)器的 LTPA 導(dǎo)出并存為 .key 文件，然后導(dǎo)入 Portal 系統(tǒng)所在的服務(wù)器（ WebShpere Application Server ）中就可以了。

1.3 .2   憑證保險(xiǎn)庫(kù) 技術(shù)是如何實(shí)現(xiàn)的

1.3 .2.1   概述

WebSphere Portal 提供了 Credential Vault （憑證保險(xiǎn)庫(kù)）功能 ， Credential Vault 通過(guò) Basic Authentication Header 將用戶名和密碼傳遞給后端應(yīng)用程序。為了使 Domino 服務(wù)器接受通過(guò)這個(gè)頭部傳遞進(jìn)來(lái)的憑證，必須將服務(wù)器會(huì)話驗(yàn)證配置為 Single-Server 模式。在 Multi-Server 模式中，該服務(wù)器只接受通過(guò) LTPA 機(jī)制傳遞的憑證。因此，為了與 Domino 應(yīng)用程序一起使用用于 SSO 的 Credential Vault ，必須將 Domino 服務(wù)器會(huì)話驗(yàn)證配置為 Single-Server 模式。

要使用 Credential Vault ，用戶需輸入一些憑證，輸入一次就夠了。隨后，這些憑證被存放在一個(gè)經(jīng)過(guò)加密的數(shù)據(jù)庫(kù)表中，每當(dāng)用戶訪問(wèn)該 P ortlet 時(shí)，這些憑證便被傳遞給后端應(yīng)用程序。要了解關(guān)于配置 Credential Vault 的細(xì)節(jié)， 請(qǐng) 參見 WebSphere Portal InfoCenter 。

1.3 .2.2 　憑證保險(xiǎn)庫(kù)實(shí)現(xiàn) SSO 原理

下面以一個(gè)最簡(jiǎn)單的 SSO 過(guò)程為例進(jìn)行介紹。

  普 通業(yè)務(wù)系統(tǒng)的登錄過(guò)程：系統(tǒng)首先提供一個(gè)頁(yè)面，讓我們輸入應(yīng)用程序中的用戶信息。

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

接下來(lái)提交到數(shù)據(jù)庫(kù)驗(yàn)證用戶信息的合法性，如果合法，則定位到授權(quán)信息頁(yè)面；否則，重定位回到登錄頁(yè)面 login.jsp 。

在 Portlet 開發(fā)中是如何解決這個(gè)問(wèn)題的？

其實(shí)起關(guān)鍵作用的還是 check_login.jsp 頁(yè)面，它需要獲得用戶名和密碼兩個(gè)鍵值，然后拿著這兩個(gè)參數(shù)到后臺(tái)數(shù)據(jù)庫(kù)去驗(yàn)證。在常規(guī)的登錄方式中，這兩個(gè)參數(shù)是通過(guò) login.jsp 獲得的。事實(shí)上，只要 Portlet 能為該頁(yè)面提供這兩個(gè)鍵值，也就實(shí)現(xiàn)了登錄的自動(dòng)化。而 Portlet 要得到這兩個(gè)參數(shù)是非常簡(jiǎn)單的，所以實(shí)現(xiàn)單點(diǎn)登錄也就非常簡(jiǎn)單了。我們可以復(fù)制一個(gè) check_login.jsp 文件，例如名為 check_portal_login.jsp ，這個(gè)頁(yè)面的兩個(gè)參數(shù)是 Portlet 提供的，剩下的事完全交給業(yè)務(wù)系統(tǒng)去處理，頁(yè)面流轉(zhuǎn)和全線控制都不用我們管了。

1.3 .2.3 　開發(fā) Portlet 實(shí)現(xiàn) SSO 的方法

（ 1 ） JSP 取值傳送 URL

我們開發(fā)一個(gè)使用系統(tǒng)專用槽的 Portlet ，使用憑證保險(xiǎn)庫(kù)的相關(guān)接口在 PortletView.jsp 中取出用戶存儲(chǔ)在憑證保險(xiǎn)庫(kù)中的鍵值，然后以 URL 的方式傳送到 iFrame 內(nèi)。

PortletView.jsp 的部分代碼如下：

如果用戶已經(jīng)在憑證保險(xiǎn)庫(kù)中存儲(chǔ)了鍵值，那么該 Portlet 的 View.jsp 頁(yè)面被初始化時(shí)， iFrame 中將顯示用戶成功登錄后的授權(quán)信息，也就是實(shí)現(xiàn)了 SSO 。

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

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

（ 3 ） Class 寫 Session ，單點(diǎn)登錄代理取 Session

我們?cè)? Portlet 的控制類中取得用戶存儲(chǔ)在憑證保險(xiǎn)庫(kù)中的鍵值對(duì)，并在 PortletView 的 doview() 方法中寫入 Session 。而專為 Portal 開發(fā)的協(xié)助登錄頁(yè)面則會(huì)直接從 Session 中取出用戶憑證，具體的操作方法略過(guò)。

由于這幾種方法開發(fā)起來(lái)比較簡(jiǎn)單，所以這里就一帶而過(guò)，不再詳細(xì)介紹了。