有几种单点登录的解决方案，本文中将探讨四种特殊的部署场景。没有哪一个解决方案比其他的更好，知道这一点是重要的。这总是依赖于组织的基础设施，以及管理员所必须遵守的规则。对于组织的一些部门而言，LDAP 是公司目录，所有更改都必须在其中进行。对于其他的部门，却不允许修改 LDAP 架构，所有的修改都需要在 Domino 目录中进行。（有关 LDAP 架构和 Domino 架构的详细信息，请参阅 这个副文件。）
可能在特定的情况下，由于 SSO 以外的其它原因，组织需要同时访问 LDAP 目录和 Domino 目录。例如，TSGA 具有一个特殊的库存系统，用于统一调配发生故障、损坏和绝密的设备。该库存系统需要访问 ITDS LDAP 目录，这个目录中存放一些“特殊设备”目录对象，所以在他们的环境中 Directory Assistance 被配置为指向 ITDS LDAP 目录。既然这样，管理多个配置目录之间的关系，将是部署 SSO 的关键之处。
总之，在本文后面部分进行研究的 SSO 场景中，一些场景在 Domino 目录中管理 SSO 信息，与此同时其他的场景在 LDAP 目录中管理 SSO。还有涉及到 Directory Assistance 的场景。在多个场景中您很可能找到一种非常适于您组织的基础设施和需要的场景。您所选择的 SSO 配置始终依赖于组织未来的需求。
虽然在多种场景中 SSO 的实现方法是不同的，但是请注意在所有的情况下，Bland 总是首先登录 WebSphere Portal Server，并且将创建包含他的 ITDS 身份 uid=jb013 的 LtpaToken。
让我们从描述最通常、最基本的场景开始。该场景描述了如何管理 Domino 目录中的 SSO 信息。
当 Bland 切换到 DWA portlet 时，LtpaToken 包含的 jb013 通过 HTTP 发送。然后 Domino 服务器将如何允许 Bland 访问他的 DWA 邮件文件呢，特别是当这个文件上的 ACL 条目允许 cn=Jim Bland/ou=secret/o=spies 进行访问时？很简单，管理员可以修改 Bland 的个人文档，添加 uid=jb013/ou=secret/dc=spies/dc=com 到他全名称域的辅助值（参见图 1）：
图 1. 个人文档
Domino Web Access 服务器将在 Domino Directory 中搜索 LtpaToken 中包含的值，并且将找到一个匹配的值，因为这个值包含在个人文档中。Domino 将这个名称解析为 Domino 专有名称（Jim Bland/Secret/Spies），这个名称包含在他的邮件文件上的 ACL 中，这样就赋予了 Bland 访问他的邮件 porlet 的权限。
进行名称映射时，TSGA 管理员必须牢记这些规则：
- 当修改 Domino 个人文件的 FullName 域时，输入“Domino 格式”的代理的 LDAP 专有名称。
LDAP 格式： uid=jb013,ou=secret,dc=spies,dc=com
Domino 格式： uid=jb013/ou=secret/dc=spies/dc=com - 在 FullName 域中添加 LDAP DN 作为辅助值。不要添加 LDAP DN 作为第一或第二个值。Domino 预期的主要值是 Domino DN，并且第二个值是 Domino 的“公用名称”。
- 一些应用程序是区分大小写的，所以要小心！Domino 不区分大小写，而其他的应用程序可能会区分。保险一些比出问题好。
- 为便于目录更改，TSGA 可能希望使用 IBM Tivoli Directory Integrator 来实现映射策略的自动执行。
场景 2：使用 Directory Assistance 进行名称映射：解析多重匹配
正如前面所叙述的：一些组织可能需要同时访问两个目录，通常情况下不是出于单点登录的原因。对于 TSGA Research Department 而言，他们的基础设施需要 Domino 服务器能够访问 IBM Tivoli Directory Server（ITDS） 以实现前面所提到的遗失设备库存系统。为使 TSGA 指定的库存 Notes 应用程序能够访问 ITDS 中的一些“特殊设备”目录对象，管理员为 ITDS 目录在 Domino 服务器上的 Directory Assistance 数据库中创建了 LDAP 条目（服务器还运行 Domino Web Access）。
要像前一个场景中那样在这个环境中实现 SSO，TSGA 添加值为 uid=jb013,ou=secret,dc=spies,dc=com 的 LtpaToken 到 Domino 中的个人文档。这引发了一个新的问题。名称 uid=jb013,ou=secret,dc=spies,dc=com 现在存在于两个位置：用户的 ITDS 条目，以及 Jim Bland/Secret/Spies 的 Domino个人文档中。同时在 Domino Directory 和 ITDS 服务器上都为 Bland 找到了匹配，当 DN（专有名称）不同的时候，Domino 服务器将如何处理呢？Domino 服务器将如何确定他们是同一个人呢？
最新发布的 Domino 6.x 和 7.0 版本处理了当解析 Directory Assistance 时用户条目存在于多个位置的名称映射场景。Domino 需要 Domino 个人文档和 LDAP 记录保持一致；因此 Domino 现在将需要额外的步骤，以确定在两个目录中的“Internet 地址”域有匹配的值。要实现此目的，DA 连同与 Notes 域 InternetAddressalong 等效的 LDAP 属性一起，为身份 uid=jb013 发布了一个搜索查询。对于 LDAP 而言，等价的属性是 mail。
| LDAP 目录中的属性 | Domino Directory 中的属性 |
| mail: JBland@secret.spies.com | InternetAddress: JBland@secret.spies.com |
最后一行表明，如果 TSGA 的环境中 DA 指向包含 SSO 身份的 LDAP 目录，那么管理员必须确保 Domino 的“Internet address”属性值与 LDAP 的“mail”属性值相匹配。
有关 Domino 和 Directory assistance 如何处理名称映射的其他信息，请参阅 Notes/Domino 6.0.4 版本说明 中的“WebSphere and Domino names handled by Domino HTTP server”。
图 2、3、4 和 5 展示 Jim Bland 的 SSO 过程，此时的 Directory Assistance 指向 LDAP 目录，LDAP 目录中包含添加了相同 uid 的个人文档，在图 2 中：
A. Bland 浏览到他的 DWA portlet。门户传送 LtpaToken 到 Domino Web Access 服务器，Domino Web Access 服务器在 Domino 目录中查找 uid=jb013,ou=secret,dc=spies,dc=com。
B. Domino 在主目录中 Bland 的第三个 FullName 值中，为 uid=jb013,ou=secret,dc=spies,dc=com 找到了一个匹配的值，这个值位于带有 Domino 专有名称 Jim Bland/Secret/Spies 并属于用户的个人文档中。
图 2.带有 Directory Assistance 的 SSO（步骤 A 和 B）
在图 3 中：
C. 已经配置了 Directory Assistance，因此将为指定的 LDAP 目录发布搜索查询。LDAP 搜索：
BaseDN: ou=secret,dc=spies,dc=com
Filter: uid=jb013
attrs to return: "mail"
D. IBM Directory Server 返回一个匹配，以及要查找的 mail 属性值：mail=JBland@secret.spies.com。
图 3.带有 Directory Assistance 的 SSO（步骤 C 和 D）
在图 4 中：
E. “mail”中的内容与“InternetAddress”中的内容相匹配吗？换句话说，在 Domino 个人文档中的 InternetAddress 属性值与 ITDS 中的 mail 属性值相匹配吗？
图 4. 带有 Directory Assistance 的 SSO（步骤 E）
最后，在图 5 中：
F. 基于每个记录中的邮件地址进行匹配，验证了 ITDS 记录和 Domino 个人文档所代表的是同一个人（Jim Bland）。成功地进行了从 LDAP 名称到 Domino 名称的映射，并允许 Bland 访问他的邮件文件。
图 5. 带有 Directory Assistance 的 SSO（步骤 F）
场景 3：通过修改外部 LDAP 架构和 DA 进行名称映射
在多种 TSGA 组织中，LDAP 是所选择的公司目录。在 LDAP 并且仅在 LDAP 中，制定了用于管理目录架构的添加、删除和修改的策略和过程。在本例中，修改和更新主要通过 IBM Tivoli Directory Server 实现，并且在 Domino Directory 中不允许修改。在 Domino 6.0 中，随着 versatility 这一新特性的加入，这样做已不成问题了。TSGA 管理员可以选择修改公司 LDAP 目录，添加 Notes 专有名称（DN）作为用户 LDAP 标识的 属性。在 Bland 的例子中，Notes 专有名称作为他的 uid=jb013,ou=secret,dc=spies,dc=com 条目属性添加到 IBM Tivoli Directory Server 中。添加一个 LDAP 域到 Directory Assistance，以指向公司 LDAP 目录服务器。如果 TSGA 按照这一策略添加信息到 LDAP，那么就无需修改 Domino 个人文档（也就无需修改 FullName 域的辅助值）。
管理员随后必须决定选择哪个 LDAP 属性，随同 Notes 专有名称填充到 IBM Tivoli Directory Server 中。这个属性可以是 LDAP 架构中现有的属性，管理员也可以选择扩展 LDAP 架构，创建一个全新的属性。不管使用何种方法，这个属性必须是 DN 语法类型的。有关属性语法类型的详细信息，请参阅 RFC 2252。
一旦选中了属性，TSGA 管理员就可以通过 LDAP 样式的语法，为每一个要进行 SSO 的身份添加 Notes DN。假定管理员选择创建一个称作 NotesDN 的新属性，这个属性将成为 IBM Tivoli Directory Server LDAP 目录中个人架构的一部分。然后添加 Notes 专有名称 cn=Jim Bland, ou=secret, o=spies 作为 NotesDN 属性的值。要进行 SSO 配置，管理员为 DA Domain 条目选择 LDAP 附签（参见图 6），在“Attribute to be used as Notes Distinguished Name”域中添加 LDAP 的属性 NotesDN ，并确保在 Naming Contexts (Rules) 附签上设置了“Trusted for credentials”。我们的 TSGA 人员还为 LDAP 层次结构校验所有的命名上下文规则是否正确。也就是说，IBM Tivoli Directory Server (ou=secret,dc=spies,dc=com) 中的目录层次结构不同于 Domino (ou=secret/o=spies) 中的目录层次结构。验证在 DA 中正确定义了这些规则。有关 Directory Assistance Naming Contexts 的更多信息，请参阅 Domino Administration Guide 中的 Directory 服务和命名规则。
图 6. Directory Assistance LDAP 附签
图 7、8、9 和 10 展示 Jim Bland 使用这一新特性通过 SSO 环境过程中发出的请求。在图 7 中：
A. Jim 浏览到他的 Domino Web Access portlet，门户传递 LtpaToken 到 DWA 服务器，这个服务器在 Domino 目录中搜索 uid=jb013,ou=secret,dc=spies,dc=com。不同于前面部分中讨论的场景，Domino 目录中不存在 uid=jb013,ou=secret,dc=spies,dc=com 。
B. Domino 目录配置为带有 Directory Assistance。Directory Assistance 配置为带有“Attribute to be used as Notes Distinguished Name”特性。
图 7. 带有“Attribute to be used as Notes Distinguished Name”特性的 SSO（步骤 A 和 B）
在图 8 中：
C. 为 uid=jb013 配置了一个需要返回 NotesDn 属性的 LDAP 搜索查询。LDAP 搜索：
BaseDN: ou=secret,dc=spies,dc=com
Filter: uid=jb013
attrs to return: "NotesDN"
D. IBM Directory Server 返回一个包含 cn=Jim Bland,ou=secret,o=spies 值的 NotesDN 属性的匹配。
图 8. 带有“Attribute to be used as Notes Distinguished Name”特性的 SSO（步骤 C 和 D）
在图 9 中：
E. 由于返回了 NotesDN，uid=jb013/ou=secret/dc=spies/dc=com 格式的名称被映射到保存在邮件文件 ACL 中的 Notes 专有名称。
图 9. 带有“Attribute to be used as Notes Distinguished Name”特性的 SSO（步骤 E）
在图 10 中：
F. 允许 Jim Bland 访问他的 Domino Web Access 邮件文件。
图 10. 带有“Attribute to be used as Notes Distinguished Name”特性的 SSO（步骤 F）
场景 4：使用 LDAP 协议进行名称映射的 IBM 合作组件
到目前为止，我们的场景很容易理解和部署。做好准备，事情将变得更加复杂。在这个场景中，将集中于对 Domino 扩展产品家族的 SSO 需求的探讨。
模型在不断的发展中，Jim 决定与 Agent 009 关于 Dubuque 的现况进行即时消息交换。稍后他计划从他的 WebSphere Portal Server 门户页面，访问 TSGA Agent Team Workspace。他现在使用 IBM 集成环境中为 SSO 提供的两个合作组件：Sametime 和 Quickplace。为 SSO 设置了 Sametime 和 Quickplace（它们接收同一个包含登录用户名称“;uid=jb013...”的 LtpaToken）。与前面例子中的 DWA 不同，Sametime 和 Quickplace 都配置为通过 LDAP 协议在 Domino Directory 中搜索用户，而不是使用基于本地 Domino NRPC 协议的 Domino Directory 接口。当 Sametime 或 Quickplace 服务器向 Domino 请求包含在 LtpaToken 中的身份时，将使用 LDAP 协议进行请求；因此 Domino LDAP 服务器将收到请求并开始进行搜索。
如果 Domino Server 在其目录中找到了一个匹配，它将为请求者返回 LDAP 语法格式的 Domino DN，“cn=Jim Bland,ou=secret,o=spies”。接着 Sametime 或 Quickplace 的任务是确定“cn=Jim Bland,ou=secret,o=spies”是否真的与 LtpaToken 值 “uid=jb013,ou=secret,dc=spies,dc=com”是同一身份。实质上，Sametime 和 Quickplace 服务器现在负责进行名称映射。这与前面的场景不同。在应用程序通过 HTTP（对于 TSGA，是一个 DWA portlet）访问 Domino 的情况下，Domino Web Server 将接收请求并使用 Directory Assistance 在本地创建 LDAP 查询，因此 Domino Directory 将处理全部所需的名称映射。尽管如此，在我们现在研究的情况下，Domino 和 Directory Assistance 没有承担处理名称映射的责任，相反 Sametime 和 Quickplace 必须处理名称映射。正如前面所提到的，通过 LDAP 进行目录搜索是 Sametime 和 Quickplace 实现名称映射的途径。
要完全实现这些，无所不知、无所不能的 TSGA 管理员必须进一步地提高技艺才可以做得出色：
TSGA 管理员必须实现名称映射，在 Domino 的个人文档中，添加 LDAP DN 作为 FullName 域的辅助值。TSGA 管理员还必须为各个 LDAP 客户端启用 LDAP 别名非关联化；在这种特定的情况下，是 Sametime Links 客户端以及 Quickplace 客户端。要使 LDAP 服务器发现在 Domino 的个人文档中 FullName 域中作为辅助值列出的 LDAP 名称，当进行名称搜索时，LDAP 客户端就必须请求 LDAP 服务器进行非关联化别名。LDAP 别名和 Notes 别名是两个不同的概念。从根本上说，LDAP 别名是 LDAP 或 X.500 目录中的一个条目，这个条目指向目录层次结构中的另一个条目。对于 Notes，别名是 FullName 域或 ShortName 域中任意的辅助值。要使 Domino 服务器解析别名（例如，如同“uid=jb013...”的 LDAP 名称）到 Domino 专有名称，LDAP 服务器必须接收来自启用了 Dereferencing of Aliases 的 LDAP 客户端的请求：
| Sametime | Quickplace |
| 添加到服务器上的 Sametime.ini 文件的 [Directory] 部分：ST_DB_LDAP_DEREF=3 | 不需要变量；在默认情况下，Quickplace 会启用它。 |
必须同时在 LDAP 服务器上启用 LDAP 别名非关联化：默认情况下，Domino LDAP Server 没有启用非关联化别名。TSGA 管理员需要从主 Domino 目录中的 Configurations 选项打开全局配置记录 *-[ALL Servers] ，选择 LDAP 附签，并设置“Allow dereferencing of aliases on search requests?”为 Yes （参见图 11）：
图 11. Configuration Settings LDAP 附签
升级 Sametime 和 Quickplace 服务器到最新版本（要进行多目录配置，还需要修补程序）。
还有更多需要知道的知识。Sametime 管理员可以查看 这个副文件 学习更多的 Sametime 管理技巧，Quickplace 管理员可以查看 这个副文件 获取更多 Quickplace 相关信息。
  |
|
Jim Bland 梦想着充满刺激和危险的激动人心的任务。但是，他目前的行动可能没有任何的生死场景。对于 SSO 却不能这样说。通过对多目录、多身份技术的不断学习，您的防范意识可能已经松懈下来了。但是我们必须让您注意一些有关名称中包含特殊字符的严重问题。在 SSO 场景中，名称包含的特殊字符会引起立即死亡。
Domino 专有名称与 LDAP 专有名称在格式上有很大的不同。正如前面所提到的，Domino 使用斜杠分隔符，而 LDAP 使用逗号分隔符。各种 IBM 产品都具有将名称从一种格式转换为另一种格式的实现逻辑。但是除了分隔符，Domino 格式和 LDAP 格式的名称还有很多其他语法上的不同，必须要正确地处理这些不同。尤其是当下列字符出现在 LDAP 名称中时，需要进行特殊的处理：
- 小于号 <
- 大于号 >
- 分号 ;
- 逗号 ,（在名称中, 不允许用作分隔符）
- 加号 +
- 双引号 "
- 反斜杠 \
- 空格或 # 出现在字符串的开始位置
- 空格出现在字符串的结束位置
在 SSO 场景中，当 LTPA cookie 中的名称从 LDAP 格式转换到 Domino 格式时，带有特殊字符的名称可能会引发问题，反之亦然。然而名称对 SSO 至关重要，如果在传输的任何环节中，交付的名称不被识别，那么很显然 SSO 会终止。下列软件必须加以配置以进行适当的转换作业。可以通过获取最新、最完整的版本，来避免在您的环境中出现立即死亡场景。要确保对 SSO 名称中的特殊字符进行正确的处理，您应该升级到 Domino 6.5.4 或更高版本。
同 Domino 扩展产品家族一样，在 Collaborative Portlets 中包含特殊字符的名称也会引发问题。如果已经部署了 WebSphere Portal 5.1 的早期版本，您可能需要进行修补以处理带有特殊字符的名称。同样，Quickplace 和 Sametime 服务器也需要修补以支持特殊字符。
|
|
现在，在多身份的场景中，用户必须总是首先登录 WebSphere （或者是 WebSphere 组件，例如门户）。WebSphere 必须创建 LTPA cookie，其中放置 WebSphere 能够识别的用户的 LDAP 名称。SSO 工作得很好因为 Domino 非常灵活，并且能够配置为接受 LTPA cookie，LTPA cookie 带有 WebSphere 可识别的 LDAP 名称。但是，反过来却存在问题：在一个多身份场景中，WebSphere 在接受 Domino 格式的名称时遇到了麻烦。为什么名称是 Domino 格式的呢？如果用户首先登录到 Domino，Domino 创建了 LTPA cookie 并将 Domino 格式的名称放入其中。当 WebSphere 接收到 cookie 并在其中搜索名称时，SSO 中断了，因为在 WebSphere 用户目录中没有找到 Domino 名称。为使 WebSphere 足够灵活，可以接受 Domino 名称，将必须在 WebSphere 端编写一些定制的代码。尽管定制的解决方案能够加以部署和被支持，但是这通常不是所期望的策略，相反，只需简单地建议您的用户，让他们首先登录到 WebSphere。革新就要出现了。为了方便用户，Domino 7 取消了用户必须首先登录到 WebSphere 这一局限。在 Domino 7 中，提供了允许用户首先登录到 Domino 的配置选项。思路是这样的，管理员选择放入到 Domino 7 为用户创建的 LTPA cookie 中用户名称的类型。不是将 Domino 格式的名称放入到 LTPA cookie 中，而是可以将 Domino 7 配置为将 LDAP 名称放入到 LTPA cookie 中。为尽可能地提高 SSO 的互操作性，管理员应该选择 Domino、WebSphere 以及其他 Domino 扩展产品能够接受的名称格式。
Domino 7 的用户现在就可以尝试这个新功能。第一步是翻转一个开关，表示您想要配置 LTPA 用户名称。这个开关位于 SSO 配置文件的一个新域中（参见图 12）。如果不翻转这个开关，那么 Domino 会继续将用户的 Domino 名称放入到 Domino 为用户创建的 LTPA cookie 中。如果翻转了开关，那么 Domino 将查找 LDAP 配置的名称以便将其放到 LTPA cookie 中。
图 12. Map names in LTPA tokens 域
在 Domino 7 个人文档中，添加了一个新域用于指定 LTPA 用户名。如果在 LTPA 令牌中为映射名称启用了 SSO 配置，就会参考个人文档中的这个域。在“LTPA user name”个人文档域中，管理员可以配置 Jim Bland 的 LDAP 名称，该名称能被 WebSphere 和 Domino 接受。这就是 Domino 7 放到 Domino 为 Bland 创建的任何 LTPA cookie 中的名称。请注意，必须将配置后的 LTPA 用户名以 Domino 格式输入到个人文档中，用斜杠代替逗号。但是不必担心，当 Domino 创建 LTPA cookie 时，在将名称放到 cookie 中之前，它会从 Notes 格式转化为 LDAP 格式，并且根据需要处理名称中的特殊字符。
当然，有些用户没有 Domino 个人文档。相反，这些用户将用户记录保存在外部 LDAP 目录中。在这种情况下，Domino Directory Assistance 用于定位 LDAP 目录中的用户。由于这些用户没有 Domino 个人文档，显然，在 LTPA 令牌中为映射名称启用了 SSO 配置的情况下，个人文档中的新 LTPA 用户名域不能使用。对于 LDAP 目录中的 Domino 用户来说，管理员可以代替其在 Directory Assistance 文档中配置 LTPA 用户名。在 Domino 7 中的 Directory Assistance 配置中，有一个新域，“Attribute to be used as name in an SSO token”。通常，管理员将用特殊的关键字 $DN 填充该域。$DN 关键字是表示应该将用户的 LDAP 专有名称放到 LTPA cookie 中的快捷方法。只要 Domino 为外部 LTPA 目录中的任意用户创建了 LTPA cookie，如果已经将 $DN 配置为用作 SSO 令牌中的名称属性，Domino 会将用户的 LDAP 专有名称放到 cookie 中。
|
|
在我们故事的结尾，是您从黑暗中走出来并成为 SSO 操作英雄的时候了。如果选择接受任务，那么您的任务将是帮助办公室中的所有 Jim Bland 高效地工作。没有比这更好的奖赏了。
在本文章系列中，我们希望为您提供了部署 SSO 之前需要具备的信息，特别是如果您的环境包含多目录和多身份。可能您现在了解了更多有关 SSO 是如何工作的知识，以及如何为根据多个名称识别用户而选择基础设施。如何选择将取决于您的管理策略。IBM 提供了用于管理 Domino 目录和外部 LDAP 目录中的 SSO 信息的解决方案。一旦开始进行 SSO 目录部署，您的任务可能包括配置 Sametime 和 Quickplace，请记住我们在多身份环境中成功部署的特殊技巧。您作为管理员，必须配备所有适当的武器，这样您的用户才能成功地并且可靠地穿行于 SSO 魔幻世界。
我们已经看到我们的英雄 Jim Bland 可以轻松地驾驭启用了 SSO 的 Web 门户。同时，Bland 的老板 VM 也很高兴地看到 SSO 使 Bland 的工作效率大幅度提高。在 Bland 进行工作的时候，他无需再面对多次身份质询了。这个完全集成的 SSO 环境的惟一“缺点”是，在每一次通过身份验证时，他不会再听到他的名字被读出来。通过功能齐全的 SSO，Jim Bland 可以确信当电梯的门打开时，一定会有可供他行走的地板。为 SSO 竖起两个大拇指吧！
