本文詳細講述了 IBM WebSphere Portal 和 Lotus Domino 之間單點登錄的核心功能，目的在於使您對這種功能有個基本的理解，併爲兩個環境協調共存時所面臨的潛在困難提供瞭解決方案。
WebSphere Portal 和 Lotus Domino之間單點登錄的技術討論
  |
|
IBM WebSphere Portal 爲 IT 公司帶來了巨大的價值，使他們能夠創建強大的 Web應用，這些 Web 應用允許用戶集中地訪問，並提供個性化信息。公司可以從門戶中獲益，比如簡化基礎設施，加快開發進程，以及提高僱員工作效率。
同樣，e-Workplaces 可以轉變僱員與客戶、其他內部成員以及供應商之間的聯繫方式。協作門戶（collaborative portal）的基礎之一，就是它所具有的通過利用協作應用使地理上分散的團隊聚在一起解決業務問題的能力。
爲了帶來這種轉變，人們通常錯誤地認爲這些協作應用需要在和門戶相同的技術平臺（比如J2EE）之間進行移植，並由於複雜性和螺旋式上升的成本而放棄它們的整合（以及潛在的門戶部署）。
與這種錯誤的設想相反，通過這種轉變獲得最大價值的關鍵在於，將 Domino 成功地整合到 WebSphere Portal 環境中以及更具體地實現兩個平臺之間的單點登錄（single sign-on，SSO）的能力。這是本白皮書重點關注的關鍵能力。提供跨 WebSphere 和 Domino 服務器的一般登錄或者單點登錄，這是這兩個應用環境之間的一個主要整合點，同時也使得公司能夠結合利用 WebSphere 服務器在事務方面的優勢和 Domino 服務器在協作方面的優勢。這種整合所產生的 Web 應用同時擴展了這兩種環境的性能。雖然這些 Web 應用實際運行在不同的應用服務器上，但是它提供了允許用戶只需一次登錄到站點的內建機制或者上下文環境，從而保持了應用外觀的無縫性，並給 IBM 爲當今市場而推出的 WebSphere Portal 戰略提供了強大的動力，這個戰略便是將 WebSphere Portal 作爲單獨的訪問點，以提供個性化的和可定製的數據。
本白皮書剩下的部分詳細講述了 IBM WebSphere Portal 和 Lotus Domino 之間單點登錄的核心功能，目的在於使您對這種功能有個基本的理解，併爲兩個環境協調共存時所面臨的潛在困難提供瞭解決方案。
|
|
本白皮書的目的是討論有關在 WebSphere Portal 環境中使用 Lotus Domino 和 Lotus Collaborative 產品的問題。本白皮書將討論有關使 Lotus Collaborative 產品內聚地在 WebSphere Portal 框架中工作的幾個場景，以及在該環境中 Domino Directory Assistance(Domino目錄服務) 的配置。本白皮書的重點是有關使用 WebSphere Portal 和Domino 中的原有工具來提供單點登錄的體驗。
|
|
本文檔面向的讀者是 Domino 和 WebSphere Portal 管理員或者IT 架構師，他們需要使用這些產品原有的 SSO 功能將 WebSphere Portal 整合到現有 Domino 環境。本文檔不討論使用其他產品（比如 Tivoli Access Manager）實現 SSO 的問題。
Tivoli Access Manager(TAM) 解決方案對於那些想要在不同類型的 Web 應用（包括WebSphere Portal和Domino以外的產品）之間集中集成安全性的客戶，或者是那些需要靈活的認證備選方案（標記、證書等等）和增強的訪問控制機制（每日一次檢查、每週一天檢查等等）的客戶，以及那些爲了安全性和 SSO 架構而選擇了 TAM 的客戶，都是最爲適合的。
嚴格地說，單點登錄指的是允許用戶登錄到一個應用，這個應用帶有經過認證的到其他應用的訪問途徑，登錄到這個應用之後，用戶無需再遭遇任何其他的認證。用更實際的話來說，它包括可以將這次主要的登錄映射到其他應用中用於同一個用戶的登錄的機制。
我們的目標是，SSO 提供登錄到 WebSphere Portal 的能力，並允許使用那些用戶憑證訪問 Domino 環境、Domino、Sametime、QuickPlace 以及其他基於 Domino 的工具。如果在 WebSphere Portal 和 Domino 環境之間沒有 SSO 關係的話，那麼用戶每次訪問某個包含來自於基於 Domino 的應用程序或者服務的信息的 portlet 時，都需要登錄到 Domino 環境中。此外，有些 WebSphere Portal API和服務，比如 人員在線感知 ，沒有提供登錄工具。即使這些服務不提供獨特的登錄工具，爲了運行它們仍然需要通過 SSO 進行認證。
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 。
大多數公司都希望能夠提供一種自動化的方法來使用當前來自於 WebSphere Portal 的憑證，以便對後端應用程序進行認證。
WebSphere Portal 和 Lotus Domino 之間的單點登錄是通過一種稱爲輕量級第三方認證(LTPA)的機制來實現的。WebSphere 應用服務器（還包括 WebSphere Portal 和其他任何運行在 WebSphere 環境中的應用程序）和 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分鐘。
- 數字簽名：用於確認標記。
本文檔不打算討論這種方法的安全性，而是要討論如何啓用和使用所提供的機制。要了解有關於 LTPA 機制的更多信息，讀者應該參考 IBM Redbook： IBM WebSphere V4.0 Advanced Edition Security(http://www.redbooks.ibm.com)。要獲得更完整的安全解決方案，IBM提供了 Tivoli Access Manager。
|
|
文檔的這一部分論討論用於建立 WebSphere 和 Domino 之間的 SSO 的選項。它被分解爲大量的場景，這些場景代表在客戶站點出現的各種各樣的環境。如果您已有一個環境，應該閱讀與您的環境最匹配的部分。如果您正在創建一個新的環境，您應該閱讀所有這些部分並選擇提供了您所需功能的場景。
這些場景分爲以下兩類：
一個目錄同時爲 WebSphere Portal 和 Domino 服務
這種場景代表一些環境，在這些環境中，一個單獨的 LDAP 目錄被用於 WebSphere Portal 環境。如果 Domino 存在於這種環境中，那麼 Domino 服務器提供 LDAP 服務，否則它就是受支持的或者使用Domino支持的 LDAP 服務器之一。如果 Domino 只是用於支持 WebSphere Portal 中的 QuickPlace 和 Sametime（它們是基於 Domino 的應用程序），那麼可以將它配置爲使用一個非 Domino 的 LDAP 目錄。如果 Domino 用於 WebSphere Portal 環境之外，它通常被用作 Web 應用服務器，而不是用於電子郵件服務。WebSphere Portal 配置爲根據該目錄對用戶進行認證。您應該注意到，WebSphere Portal（和 WebSphere Application Server）可以配置爲僅根據單獨的一個 LDAP 目錄來進行認證。
對於整個企業來說，將 Domino 服務器當作 LDAP 服務器使用是有可能的。 Domino 服務器提供了對 LDAP 的支持， LDAP 可用於從 WebSphere Portal 以及其他應用進行認證。如果 Domino 將用作企業 LDAP ，那麼該環境就會被看作單目錄環境。
分離 Domino 目錄和 WebSphere Portal 目錄
在這些場景中，通常環境中都已有 Domino 基礎設施，對於 Domino 和 WebSphere Portal 都有分離的目錄。通常情況下，Domino 目錄包含了有關每個 Domino 用戶的信息，而公司 LDAP 目錄包含了該羣體的一個超集。公司 LDAP 目錄必須包含針對每個要訪問 WebSphere Portal 的用戶的用戶記錄。在給定用戶也是 Domino 用戶的情況下，有一些信息必須在兩個記錄之間進行協調。這通常是手工完成或者用工具完成，比如用IBM Directory Integrator（IDI）。
要使這種方法奏效，必須在 WebSphere Portal 環境和 Domino 環境之間建立單點登錄 LTPA 關係。參見 Portal InfoCenter 和 WebSphere Portal Release Notes中有關配置服務器的信息。
注意，即使沒有建立 LTPA 關係，仍然有可能看到一些來自於 WebSphere Porta的類似於 SSO 的行爲。這是因爲有兩種不同的方法可用於認證從 WebSphere Portal 進入 Domino 環境的用戶。要理解這兩種方法是如何工作的，明白從 WebSphere Portal 到 Domino 的整合點就很重要。
portlet 整合了 WebSphere Portal 和後端應用程序，當用戶要請求來自一個外部應用的信息並將其顯示在 WebSphere Portal 頁面中時，portlet 充當的是某種代理的角色（這並非嚴格的意義上的說法，但是 portlet 的確會執行一些相同的功能）。Notes Mail portlet 演示了這種行爲。WebSphere Portal以用戶名向 Domino 服務器請求數據。WebSphere Portal 使用當前用戶憑證（它是從會話信息中蒐集到的）請求 Domino 服務器中的信息。然後，portlet 格式化該請求，並將該請求發送到 Domino 服務器。當數據返回時，它已被格式化並加入到 WebSphere Portal 頁面，然後發送到用戶瀏覽器中以供查看。
當登錄到 WebSphere Portal 時，您需要使用 LDAP 屬性，該屬性通常是惟一的用戶名縮寫、僱員序列號，或者其他某些惟一的標識符。WebSphere Portal 收到對用戶的用戶名和密碼的確認，或者從 LDAP 服務器收到現有的 LTPA 標記之後，它就會蒐集其他包含完整用戶標識名（DN）的信息。然後該信息被緩存在 WebSphere Porta 上，直到用戶從該服務器上註銷或者會話終止。一旦 portlet 上聚集了該信息，該信息就建立一個 HTTP、IIOP 或者 LDAP 請求，並將它發送到 Domino 服務器。當 Domino 服務器收到該請求，它就取用戶憑證並使用 Domino 認證和授權工具來查看用戶是否有權獲得該信息。如果認證和授權獲得許可，則該信息將被檢索到並以 XML 格式傳回 WebSphere Portal。如果用戶沒有經過授權就請求信息，那麼 WebSphere Portal 就會收到返回的錯誤信息。
另外還有一種很多 Domino portlet 使用的特殊情況。當處於 Domino portlet 的配置模式時，通過 Domino 服務器的 DIIOP 接口，可以檢索到有效數據庫的列表。IIOP 連接和 HTTP 連接之間惟一的不同之處在於與 Domino 服務器交談的協議不同。發送到 Domino 服務器的 LTPA 信息與 HTTP 請求是相同的。
爲了讓這種級別的 SSO 能夠工作，DN 和相關的密碼必須在 Domino 和 WebSphere Portal 之間匹配。這是在WebSphere Portal 中爲 Domino 服務器整合提供這種級別的 SSO 所帶來的的副效應。用戶的 WebSphere Portal 用戶名和密碼將被一起傳遞。
涉及 SSO 的第二組事務出現在用戶瀏覽器和 Domino 服務器之間。當用戶從 WebSpherePortal 界面打開一個 Lotus Notes 文檔，或者在 iFrame portlet 中打開任何 Domino 應用程序時，這些事務就會發生。如果您查看一下 Notes Mail portlet 或者 Notes view portlet 中的條目，您會注意到 HTML 鏈接被定向到 Domino 服務器並繞過了 WebSphere Portal。
由於 WebSphere Portal 沒有包含在事務中，因而用戶的身份是通過 LTPA cookie來傳遞的，這個 LTPA cookie 是在用戶通過 WebSphere Portal 的認證時創建的。該 LTPA cookie 包含用戶的 DN ，這個 DN 是登錄時從 LDAP 目錄檢索到的。經過加密的 LTPA cookie 信息連同 HTTP 請求一起傳遞到 Domino 服務器。
要用 SSO 處理由 WebSphere 創建的 LTPA cookie，必須生成一個在 Domino 服務器上生成一個有效的鍵密鑰（Key）。WebSphere Administrator’s Console 在 Security Center 有一個工具，該工具可以導出一個 LTPA 鍵密鑰，之後這個鍵密鑰可以被導入 Domino 中，從而在兩個環境之間提供了公共鍵密鑰。雖然 Domino 服務器可以消費由 WebSphere 創建的鍵密鑰，但是 Domino 不能導出它自己的 LTPA 鍵密鑰。
本文檔的剩餘部分涉及如何配置 WebSphere Portal 和 Domino ，以便支持這兩種類型的 SSO。
|
|
前面已經討論過，這兩種場景適用於兩種不同的配置；一種是使用 Domino LDAP 作爲它們的主目錄的環境，另一種是將所有應用程序，包括 Domino 指向另一個支持的 LDAP 目錄的環境。
Domino 服務器提供了一種 LDAP 服務。WebSphere Portal 可以被配置爲使用 Domino LDAP 服務進行認證。這是最簡單的環境，因爲用戶憑證和密碼是從同一個源產生的（通過 LDAP 或者原始 Domino）。
惟一需要的配置步驟就是從 WebSphere 服務器中將 LTPA 鍵密鑰導出並將它導入 Domino 服務器的這一過程。相同的鍵密鑰必須在所有的 WebSphere 服務器之間共享，這些 WebSphere 服務器將會是該 SSO 域的一部分。基本的安全設置，比如超時、LDAP 服務器和 DNS 域在所有的 WebSphere 服務器中必須是一致的。
Domino 服務器在該鍵密鑰被導入後一定要配置爲 Multi-Server SSO 針對多服務器SSO。要獲得有關如何配置服務器的更多信息，參考當前的 WebSphere Portal InfoCenter 以及 Readme 文件。
Sametime 3.x 和 QuickPlace 3.x 服務器可配置爲使用原始的 Domino Directory 或者 Domino DAP服務。
WebSphere Portal 支持 IBM 的 Directory Server、Microsoft 的 Active Directory、iPlanet 以及 Novell 的 eDirectory。Domino 可被配置爲在特定條件下支持這些目錄。
爲了使郵件在 Domino 環境內部進行路由，就必須有包含郵件信息（比如郵件文件和針對每個用戶的郵件服務器）的目錄記錄。該文檔既可以是 Domino Directory 中的 Person 文檔，也可以是 Mail-in Database 文檔，或者是 LDAP 目錄中的擴展Schema。
Domino 服務器有一種用於鏈接到一個外部的名爲 Directory Assistance (DA) 的 LDAP 目錄的機制。該機制允許 Domino 服務器在爲用戶身份認證搜索 Domino 目錄後搜索一個或多個 LDAP 目錄。DA 通過從所提供的模板中創建 Directory Assistance 數據庫，在服務器文檔中輸入數據庫名稱，然後在該數據庫中加入一個文檔而被激活。
接着組和用戶管理可以從 LDAP 目錄完成，惟一的限制就是郵件路由。在 ACL 中對用戶名的引用，組成員以及其他的上下文環境需要是用戶的 LDAP DN 的經過修改的版本。修改是在 Domino 環境中完成的，在 Domino 環境中， LDAP 所使用的逗號被 / 字符替代。所以
cn=Elizabeth Somebody,ou=users,o=YourCo |
變爲
cn=Elizabeth Somebody/ou= users/o=yourco.com |
即使配置好了 Directory Assistance，要提供單點登錄的功能，您仍然需要配置 WebSphere Portal 和 Domino 之間的 LTPA 關係。QuickPlace 環境和 Sametime 環境都應該被配置爲根據與 WebSphere Portal 相同的目錄進行身份認證。要獲得更多的信息，請查看與這些產品一起提供的文檔。通過 QuickPlace 3.0 可以直接訪問 LDAP ，而無需 Directory Assistance。Sametime 3.0 依賴於Directory 幫助Assistance從 LDAP 獲得信息。爲了最靈活地實現 人員在線感知，Sametime 應該配置爲使用原始 Domino Directory。
在某些環境中使用 Directory Assistance 是奏效的，在這些環境中相同的用戶不會被列在 LDAP 目錄中，也不會被列在 Domino 目錄中。如果只爲了支持QuickPlace 和 Sametime 而執行 Domino，那麼可以使用這種類型的配置。在更復雜的環境中如果已經存在 Domino 基礎設施，需要使用更多的 Domino 功能，就有必要配置多個目錄。
|
|
雖然大多數組織的最終目標是獲得一個單獨的目錄，然而更典型的情況是，最少存在兩個目錄，甚至存在更多的目錄也是很常見的。對於非 Domino 應用程序，應該使用 Domino Directory 以及針對非 Domino 應用程序的通用 LDAP 目錄。通常都會有一個附加的專門針對某些特定應用程序的 LDAP 目錄。
WebSphere Portal 依賴於底層的 WebSphere Application 服務器進行認證。WebSphere Application 服務器被限制爲根據單獨的用戶庫（user repository）進行身份認證。這意味着所有正在使用 WebSphere Portal 的用戶必須位於主目錄（通常是 LDAP）中的一個單獨實例中。
Domino 的目錄需求則完全不同。爲了獲得 Domino 服務器的完整功能，包括郵件路由，在針對每個用戶的 Domino 目錄中需要有一個條目。在理想的情況下，擁有現存的 Domino 環境的組織將使用 Domino 目錄在 WebSphere Portal 中進行身份認證。然而，在現實中，Domino LDAP 實現中的限制、多郵件系統、特定於應用的 LDAP 需求以及其他許多因素避免了這種情形使得這種方式行不通。
將用於 WebSphere Portal 和 Domino 的目錄分開，以及在兩者之間提供 SSO，這樣的在現實中種現實的需求直接導致了一種情形的產生，我們稱這種情形爲 Multiple Identities Problem（多身份問題）。要理解如何配置不同部分以便解決相關的問題，理解這個問題的本質是很重要的。
我們將通過定義一個示例環境來討論多身份問題，該環境與通常的環境所能看到的東西類似。我們的示例公司名稱爲 YourCo。YourCo 有一個主 LDAP 目錄，在針對用戶的 ou 下，有分佈在每個城市的分公司中的用戶。所以對於我們的示例僱員 Elizabeth Somebody，在她的 LDAP 記錄中有下列信息，我們引用這樣的 LDAP 記錄作爲她的 LDAP 身份。
| 字段 | 值 |
| dn | Elizabeth Somebody,ou=Boston,ou=users,dc=yourco,dc=com |
| uid | esomebody |
在現有的 Domino 環境中，Elizabeth 的 Person 文檔包含下面的值，我們將引用這些值作爲她的 Domino 身份。
| 字段 | 值 |
| First Name | Elizabeth |
| Last Name | Somebody |
| User Name | Elizabeth Somebody/Boston/YourCo Elizabeth Somebody |
| Short Name | esomebody |
Elizabeth 用她的 LDAP uid （即 esomebody）登錄到 WebSphere Portal 中。作爲身份認證過程的一部分，WebSphere Application Server 從 LDAP 目錄中找到她的完整 DN，並用它建立 LTPA cookie。當她作爲經過認證的用戶訪問WebSphere Porta 頁面時，WebSpherePortal 的 Lotus Collaborative Components（LCC）從 WebSphere Portal 收集她的用戶信息（公用名、LDAP uid 和 DN）。然後 LCC 嘗試初始化與 Sametime 服務器的 Sametime Links 連接。在建立這個鏈接的過程中，將公用名提供給 Sametime， 以便初始化 Elizabeth，併爲 Elizabeth 提供 人員在線感知。當 Elizabeth 訪問某個包含 Notes portlet 的 WebSphere Portal 頁面時，她的 DN 通過 HTTP 傳遞給 Domino 服務器。然後 Domino 服務器搜索 Domino Directory 以期找到 DN，但是在 Domino Directory 中是找不到 DN 的（在這裏沒有使用 LTPA cookie）。
表面上顯而易見的解決方案是啓用 Domino 上的 Directory Assistance 以便將 LDAP 服務器加入到認證路徑中。當該任務完成時，對 DN 的搜索現在將轉移到該 LDAP 目錄，在該目錄中您將發現一個匹配的項並且用戶也會通過認證。問題在於 Elizabeth 是以下面的身份進行認證的：
cn=Elizabeth Somebody,ou=Boston,ou=users,dc=yourco,dc=com |
而 Domino 不知道這和下面所指的用戶是同一用戶
Elizabeth Somebody/Boston/YourCo |
Elizabeth 在 Domino 環境中所做的每一件事都將以她的 LDAP 身份進行。比如，當 Elizabeth 發送郵件時，則 From 字段就會包含她的 LDAP DN。她將能夠找到地址併發送郵件，但是如果接收者回復該郵件，他們將收到一個名稱不在目錄中錯誤（name not found in directory error），因爲不存在具有 DN 的 Domino 個人文檔。
當 Elizabeth 在 Domino 數據庫中創建文檔時，創建者元數據將包含她的 LDAP DN。如果視圖按照 Authors 字段進行分類，那麼她通過 WebSphere Portal 創建的文檔與通過 Notes 客戶機創建的文檔相比將排在不同的位置，也不同於那些在從一個 Web 瀏覽器訪問 Domino Application Directly 時創建的文檔。
如果在某些數據庫中 Elizabeth 的 Domino 身份被列在 ACL 中，無論是顯式地列出還是通過組成員，她都將不能訪問這些數據庫。這一規則對於那些具有限制的文檔來說同樣適用，這種限制可以是通過 Reader 字段施加的，也可以是通過 Author 字段施加的。
因爲有了這些限制，我們可以不再使用 DA 作爲對該問題的解決方案。真正需要的是用於將 LDAP 身份映射到 Domino 身份的一種方法。幸運的是 Domino R5 服務器提供了這種功能。
個人文檔的 User Name 字段是一個多值字段，只要有必要，它可以包含用戶名稱的許多變種。作爲最好的最佳實踐，Directory 中每個條目應該是惟一的。當根據該字段中的一個條目找到一個匹配項時，爲了達到認證目的，Domino 將身份映射到該字段的第一個條目。這通常是用戶名的分層版本。要利用這種功能並解決先前在 Domino 和 Directory Assistance 部分討論過的問題，我們需要改變 DA，然後在 User Name 字段的第二行之後添加用戶 LDAP DN（用 / 替代逗號）。
現在，當 Domino 服務器收到完整的 DN 時，它就會搜索 Domino Directory。初次的搜索仍然會失敗。如果服務器上啓用了 DA，DA 現在將會搜索 LDAP 目錄，而您將面對您先前遇到的同樣的問題。；相反否則，它檢查 User Name 字段的所有條目，並找到完整 LDAP DN（用/代替逗號）的一個匹配。然後用戶 LDAP DN與第一個條目相關聯，用戶以 Domino 身份進行認證。他們在原有 Domino 環境中的所有行爲現在都要通過他們的 Domino 身份來實現，而那些在 WebSphere Portal 環境中的行爲要通過 LDAP 身份來實現。
當使用 LTPA cookie 時，同樣的解決方案會奏效。因爲 LTPA cookie 是通過用戶的 LDAP DN來創建的， Domino 服務器將在 User Name 字段中找到那個名稱並將這個名稱與他或者她的 Domino 身份相關聯。
第一件要做的事情就是配置 Domino 環境，以便在 WebSphere Portal 服務器和 Domino 服務器之間建立 LTPA 關係。Directory Assistance 缺省情況下是關閉的。但是如果您使用 DA 級聯 Domino 地址簿，就可以啓用它。不要在 Directory Assistance 搜索路徑中包括 Corporate LDAP 目錄。
在每一個用戶的 Person 文檔中，至少需要在 User Name 字段中添加一個條目。字段的第一行應該已經包含完整的層次 Domino 用戶名。第二個條目應該是用戶的公用名（cn），它以 FirstName, LastName 的格式出現。當某個用戶被註冊時這些條目被 Domino 建立起來並應保持原樣。其他的條目，比如其他形式的公用名、婚前姓氏以及暱稱可能已經存在並就緒了。做完這件事後，我們應該加入 Domino 格式的用戶的 LDAP DN（用 / 替換逗號）。
在上面的例子中，LDAP 中用戶的縮寫名稱與 Domino 目錄中的縮寫名稱相匹配。如果不是這種情況，那麼 LDAP uid 也必須出現在 Person 文檔的 User Name 字段中。這對於其他的 LDAP 屬性，比如公用名（cn）同樣適用。如果 LDAP 記錄的 cn 不同於 User Name 字段的第二行，那麼必須將該 cn 包括在用戶名中以允許 人員在線感知 奏效。
該示例說明了 Domino User Name 字段所需的不同值：
| LDAP條目 | 舊Domino條目 | 新Domino條目 |
| cn=ElizabethSomebody, ou=Boston, o=YourCouid=esomebody |
User Name =Elizabeth Somebody/Boston/YourCoElizabeth SomebodyBeth SomebodyShortname = esomebody | User Name =Elizabeth Somebody/Boston/YourCoElizabeth SomebodyBeth Somebodycn=ElizabethSomebody/ou=Boston/o=YourCoShort Name = esomebody |
| cn=ElizabethSomebody, ou=Boston, o=YourCouid=y32483 |
User Name =Elizabeth Somebody/Boston/YourCoElizabeth SomebodyBeth SomebodyShortname = eSomebody | User Name =Elizabeth Somebody/Boston/YourCoElizabeth SomebodyBeth Somebodycn=ElizabethSomebody/ou=Boston/o=YourCoy32483Short Name = esomebody |
| cn=BethSomebody, ou=Boston, o=YourCouid=esomebody |
User Name =Elizabeth Somebody/Boston/YourCoElizabeth SomebodyShortname = esomebody | User Name =Elizabeth Somebody/Boston/YourCoElizabeth SomebodyBeth Somebodycn=BethSomebody/ou=Boston/o=YourCoShort Name = esomebody |
由於 WebSphere Portal 可能會爲某些用戶認證傳遞用戶名和密碼，所以您還需要同步 Domino 目錄和 LDAP 目錄之間的 Internet 密碼。這對於用 WebSphere Portal 進行完整的 Domino 整合是非常關鍵的。記住，在 Domino Server 和 WebSphere Portal 之間仍有事務發生，這些事務使用了用於登錄到 WebSphere Portal 的憑證。
這些需求將需要 ongoing 不斷維護。這既可以手工完成，也可以使用工具完成，比如IBM Directory Integrator。
Sametime 服務器應該被配置爲根據原始 Domino Directory 進行認證，以允許 人員在線感知。3.0 版的 Sametime 文檔推薦使用 LDAP 目錄。但是，在多目錄環境中配置 Sametime，使其使用 Native Domino 目錄，這樣做提供了更靈活的 人員在線感知。
具體的例子就是 NotesView portlet 的使用。如果爲了某一包含用戶的公用名的列而打開了 人員在線感知，那麼任何一個目錄（ LDAP 或者 Native Domino ）都可以使用。如果該列包含用戶的完整規範名稱，如果 Sametime 使用的是 LDAP 目錄，那麼 Sametime 將不能確定在線狀態。
QuickPlace 對目錄服務器進行 LDAP 調用，而 Sametime 則不同，當根據 LDAP 進行認證時 Sametime 使用 Directory Assistance。因爲 Directory Assistance 對於 Sametime 的運行是必需的，因此必須在 Sametime 上配置 DA。但這是惟一需要配置的服務器。雖然 Sametime awareness 會有效，當對運行在 Sametime服務器上的 Domino 應用程序進行認證時，您還是會碰到先前討論過的問題。
當使用 QuickPlace2.08 時，您應該配置服務器，以便將 Domino 作爲目錄來使用。當您爲 SSO 配置底層的服務器時，必須使用 domcfg.nsf 文件的一個特殊版本。這個版本在 www.lotus.com/support. 上可以下載。該文件包含一個更新後的缺省域登錄文檔，該文檔執行一些附加的處理來維護 LTPA cookie。如果您使用與 Domino 一起提供的缺省 domcfg.nsf，那麼當您訪問 QuickPlace 時 LTPA cookie 將被覆蓋，而且當您返回 WebSphere Portal 時，您將需要再次重新登錄。
QuickPlace3.0 應該配置爲訪問和 WebSpher Portal 相同的 LDAP 目錄。如果您要訪問一個現存的 QuickPlace 環境，該環境由早期版本移植而來，這可能成爲一個問題。您可能需要使用 changemember 命令來將 QuickPlaces 中的用戶名更新到它們的 LDAP 版本。這將允許用戶在該環境中維持他們的 QuickPlace 功能。
如果您有這樣一個需求，即必須要麼使用 Native Domino 目錄，要麼通過 LDAP 使用 Domino Directory 目錄，那麼這時您需要有一個補丁，該補丁支持適當的名稱映射。
利用 WebSphere Portal 環境和 Domino 環境之間的單點登錄的核心功能可以大大改善用戶體驗並提高他們的工作效率。有了本文提供的信息，您現在不僅掌握了關於如何最好地實現單點登錄的知識，而且還能更好地理解這個核心功能背後的底層細節。此外，本文檔中簡要介紹的一些方法將允許您配置 WebSphere Portal 環境和 Domino 環境，以利用它們各自的優勢。而在更復雜的環境中，需要考慮利用Tivoli Access Manager。