内容： 摘要 引言 面向的读者 场景概述 单用户目录环境 分离目录环境 结束语 关于本文的评价

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和服务，比如People Awareness，没有提供登录工具。即使这些服务不提供独特的登录工具，为了运行它们仍然需要通过 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 的整合点就很重要。

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 用户名和密码将被一起传递。

针对 Domino 的浏览器

涉及 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 目录

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服务。

使用非 Domino 目录

WebSphere Portal 支持 IBM 的 Directory Server、Microsoft 的 Active Directory、iPlanet 以及 Novell 的 eDirectory。Domino 可被配置为在特定条件下支持这些目录。

为了使邮件在 Domino 环境内部进行路由，就必须有包含邮件信息（比如邮件文件和针对每个用户的邮件服务器）的目录记录。该文档既可以是 Domino Directory 中的 Person 文档，也可以是 Mail-in Database 文档，或者是 LDAP 目录中的扩展Schema。

Domino 和 Directory Assistance

Domino 服务器有一种用于链接到一个外部的名为 Directory Assistance (DA) 的 LDAP 目录的机制。该机制允许 Domino 服务器在为用户身份认证搜索 Domino 目录后搜索一个或多个 LDAP 目录。DA 通过从所提供的模板中创建 Directory Assistance 数据库，在服务器文档中输入数据库名称，然后在该数据库中加入一个文档而被激活。

接着组和用户管理可以从 LDAP 目录完成，惟一的限制就是邮件路由。在 ACL 中对用户名的引用，组成员以及其他的上下文环境需要是用户的 LDAP DN 的经过修改的版本。修改是在 Domino 环境中完成的，在 Domino 环境中， LDAP 所使用的逗号被 / 字符替代。所以

 
cn= ElizabethSomebody,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 获得信息。为了最灵活地实现 People Awareness，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 身份。

在现有的 Domino 环境中，Elizabeth 的 Person 文档包含下面的值，我们将引用这些值作为她的 Domino 身份。

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 提供 people awareness。当 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=ElizabethSomebody,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 环境

第一件要做的事情就是配置 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 包括在用户名中以允许 people awareness 奏效。

该示例说明了 Domino User Name 字段所需的不同值：

由于 WebSphere Portal 可能会为某些用户认证传递用户名和密码，所以您还需要同步 Domino 目录和 LDAP 目录之间的 Internet 密码。这对于用 WebSphere Portal 进行完整的 Domino 整合是非常关键的。记住，在 Domino Server 和 WebSphere Portal 之间仍有事务发生，这些事务使用了用于登录到 WebSphere Portal 的凭证。

这些需求将需要 ongoing 不断维护。这既可以手工完成，也可以使用工具完成，比如IBM Directory Integrator。

Sametime 配置

Sametime 服务器应该被配置为根据原始 Domino Directory 进行认证，以允许 people awareness。3.0 版的 Sametime 文档推荐使用 LDAP 目录。但是，在多目录环境中配置 Sametime，使其使用 Native Domino 目录，这样做提供了更灵活的 People Awareness。

具体的例子就是 NotesView portlet 的使用。如果为了某一包含用户的公用名的列而打开了 People Awareness，那么任何一个目录（ LDAP 或者 Native Domino ）都可以使用。如果该列包含用户的完整规范名称，如果 Sametime 使用的是 LDAP 目录，那么 Sametime 将不能确定在线状态。

QuickPlace 对目录服务器进行 LDAP 调用，而 Sametime 则不同，当根据 LDAP 进行认证时 Sametime 使用 Directory Assistance。因为 Directory Assistance 对于 Sametime 的运行是必需的，因此必须在 Sametime 上配置 DA。但这是惟一需要配置的服务器。虽然 Sametime awareness 会有效，当对运行在 Sametime服务器上的 Domino 应用程序进行认证时，您还是会碰到先前讨论过的问题。

QuickPlace 配置

当使用 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。