如果您认为您的工作环境难于控制，让我们来研究一下 Jim Bland，一个高度机密的政府机构（称其为 TSGA）的一位秘密工作人员。和其他国际间谍一样，Jim 在一个快速运转的、高要求的环境中工作，其中的信息非常有价值。但是，与他的较出名的对手不同，Jim（徽章编号 013）必须与更传统的工作环境斗争，这些环境包括一个超负荷工作并且低预算的 IT 部门，而且，和我们中的大多数人一样，Bland 必须利用更少的资源做更多的事情。
Jim Bland 从事间谍工作，但是 Jim 只接受内部任务。Bland 现在的工作是监视那些行业巨头，这些行业巨头正在通过神秘的手段谋取不义之财。Bland 最新任务的绝密文件藏在一个受保护的存储地点（这次是商场里的一个公共休息室），要获得这份文件，Bland 必须证明自己的身份。Bland 来到后面的货摊墙壁处，把手放在闪亮的新墙砖上。这实际上是一个扫描器，读取了他的指纹。显然，Bland 通过了验证，一个声音提示道：“身份通过验证”。墙壁上露出隐藏的暗门；这个门通向电梯，电梯能够将他带到秘密文件所在的地点。Bland 进入了电梯，但是在电梯按钮被激活前，Bland 必须通过第二次验证 —— 这次是视网膜扫描 —— 声音再一次提示：“身份通过验证”。乘坐了一小会儿后，电梯的门打开了，但是有一个问题：这里没有可以踩上去的地板！相反，Bland 看见的是一个大的开放的空间，什么东西都没有。Bland 该怎么做呢？他要跳过去吗？他会晃动着爬下附近的水管吗？实际上，经验丰富的间谍确切地知道他必须怎么做：通过说出神秘的单词来再次表明自己的身份，“Bland，Jim Bland”。突然出现了一条通道，使 Bland 能够安全通行，随着语音验证了 Bland 的身份：“允许 Agent 013 进行访问”，他离开了电梯。现在 Bland 可以继续他的工作了，虽然不是拯救世界而是打击金融犯罪。但是，这个过程已经令人厌倦了，我们确信 Bland 也正在思考：“为什么我的单点登录又被破坏了？”
单点登录（也称为 SSO），虽然管理起来很复杂，但是这完全是为了方便用户，否则不断地要求用户输入登录信息会使用户很恼火。对于那些负责部署或维护 SSO 环境的人来说，本文提供了一些为用户配置具有高可靠性的复杂环境方面的技巧和窍门。您的环境可能包括一些通过语音识别来激活的隐藏通道，但是它更有可能是一个典型的 Web SSO 环境。通常的主流场景包括一个用户，系统会提示该用户输入用户名和口令，以访问包括 IBM 组件的环境，例如 WebSphere Portal 和 Domino。该环境可能还包括 Lotus portlet，通过 Domino Web Access（DWA），Lotus portlet 提供了到 Sametime、Quickplace 以及 Domino 邮件的连接。
在这个由两部分组成的文章系列中，我们集中讨论 Portal 环境，该环境极其复杂，因为要部署多个目录。像 DWA 这样的组件可能需要 Domino Directory，而其他组件（例如 Portal）可能需要用 IBM Directory Server、Active Directory 或任何其他受支持的 LDAP 目录来部署。本文解释了 SSO 是如何在部署了多种目录的环境中运作的，并重点讨论当用户有一个以上的名称时所面对的挑战。
在间谍活动领域中，间谍通常具有多个化名，同样在 SSO 场景中，用户具有一个以上的名称也是很常见的一种现象。名称在 SSO 环境中是非常关键的。为了理解它是如何起关键作用的以及为什么非常关键，我们在本文章系列的第 1 部分首先回顾 SSO 基础，解释如何在 SSO 环境中验证用户。然后讨论在运行多目录、多身份站点时所涉及到的问题。
通常，当我们讨论 SSO 时，实际讨论的是 Web 用户体验（但是，如果对 SSO 和操作系统桌面登录感兴趣，请参阅 这个副文件）。我们让用户位于 Web 浏览器中，例如 Jim Bland，他会浏览他喜欢的 URL，该 URL 位于 spycental（http://spycentral.spies.com/fun）。结构良好的 SSO 部署将允许每个会话中仅提示 Bland 登录一次。当 Bland 第一次尝试访问位于 spycental 的 URL 时，他必须输入他的用户名 jb013 和口令 LazyEye。位于 spycentral 的 Web 应用服务器成功验证 Bland 的口令，并授予他对这个 URL 的访问权限。一旦登录后，Bland 就具有了所有的相关权限。他已经获得了对 SSO 环境的访问权限，并且可以浏览该环境中的其他 URL，而无需再次登录（参见图 1）。
图 1. SSO 登录
在图 1 中：
A. Bland 浏览他感兴趣的 URL，被提示进行登录。Web 应用服务器验证 Bland 的口令并允许他访问 URL。SSO 环境现在能够识别 Bland 了。
B. Bland 浏览 SSO 环境中的另一个 URL ，而不需要重新进行登录。
要实现 SSO，关键是在用户登录后，SSO 服务器和应用程序能够识别用户。在部署了 IBM 产品的 Web 环境中，在场景后台用来实现 SSO 的神奇功能是 Lightweight Third Party Authentication（LTPA）。LTPA 技术允许 SSO 服务器在用户登录后标识他们。IBM 支持开放的标准，但是实际上不存在这样一种用于 SSO 的广泛的部署标准，IBM 已经实施了自己的 SSO 技术。LTPA 能够用于各种各样的 IBM 产品，并且由于 IBM 遵循开放体系结构，LTAP 中为 WebSphere 和 Domino 提供了嵌入点，允许将第三方 SSO 应用程序合并到 LTPA 解决方案中。为了帮助理解 LTPA 技术，以及为了证明名称是 SSO 环境中的关键问题，必须从探讨浏览器和浏览器 cookie 开始我们的故事。
设想 Jim Bland 坐在他的浏览器前，输入了一个 WebSphere URL，并被提示输入用户名和口令进行登录。通过他输入的口令，WebSphere 应用服务器验证了 Bland 的身份。接着 Web 服务器可以将应该在 Bland 的 Web 浏览器中显示的 Web 站点内容发送回来。Web 用户总是有这样的经历：Bland 输入正确的口令，并开始浏览 Web 站点。在这种情况下，在场景后台，WebSphere 会一直发送 cookie，Bland 的浏览器（参见图 2）将保存这个 cookie。请注意，要使浏览器存储 cookie，必须允许浏览器接受 cookie，这是浏览器通常的默认设置。LTPA cookie 是一个临时的 cookie，它只在浏览器的内存中存留，当 Bland 关闭他的浏览器时，cookie 将会被永久删除。
图 2. 登录会返回 LTPA 浏览器 cookie
LTPA 浏览器 cookie 是典型的浏览器 cookie。如果不了解浏览器 cookies，就请注意，cookie 是将信息保存在用户的计算机上，以备以后使用的一种标准方法。LTPA cookie 中保存的信息表示 Bland 已经进行了登录。所有的浏览器 cookies 都有一些标准属性，例如名称。LTPA cookie 特有的名称是 LtpaToken。（顺便说一下，当配置 SSO 时，在我们的配置实用工具中，通常将 LTPA cookie 称为 SSO LTPA“令牌”。这里谈到 SSO cookie，也等同于使用 SSO 令牌这一术语。）除 cookie 名称外，与所有的浏览器 cookie 一样，LTPA cookie 有一个值。在使用 LTPA cookie 的情况下，无法在第一眼看到 cookie 时理解这个值，因为这个值已经被编码。通过要求将 LTPA cookie 值编码，cookie 中包含的重要信息可以隐藏起来，通过 internet 传输。
作为典型的浏览器 cookie，LTPA 浏览器 cookie 具有相关的域信息。当 Bland 在 spycentral 登录时，spycentral 服务器创建了 LTPA cookie。spycentral 服务器在 spies.com DNS 域中，因此 cookie 域信息被设置为 spies.com。域信息表示该 cookie 只能在 spies.com DNS 域中使用。由于 LTPA 的实现依赖于具有域信息的浏览器 cookies，通常这意味着 SSO 环境必须部署到单一 DNS 域中。在我们的部署例子中，服务器是 spycentral.spies.com、spymeetings.spies.com 和 spyVsSpy.spies.com。每一台设备都在 spies.com DNS 域中。只能在单一 DNS 域中部署 SSO 这一限制，直接与 LTAP 实现的核心是带有域信息的浏览器 cookie 这一情况相关。（要了解这个 DNS 问题的解决方法，请参阅 这个副文件。）
现在已经简短地探讨了 LTPA 浏览器 cookie 的各个部分，让我们回到为什么该 cookie 在 SSO 解决方案中扮演领导角色这一根本问题上。在 Bland 已经登录并且 Bland 的浏览器接收到 LTPA cookie 后，在 HTTP 通信中，浏览器将自动发送该 cookie。不需要进行特定的配置；这只是浏览器运行的标准方法。在发送到任何正确 DNS 域中 URL 目标的每一个 HTTP 请求中，浏览器不断地向外发送该 cookie。例如，当 Bland 输入 spycentral.spies.com 域中的 URL 时，浏览器发现它拥有一个适用于 spies.com 域的 cookie，浏览器就自动地一同发送 LTPA cookie。当 Bland 访问 spymeetings.spies.com 域中的 URL 时，也会这样。在每一个可用的 HTTP 请求上，浏览器都会发送 cookie。当 SSO 服务接收到 HTTP 请求，并且发现请求中包含了 LTPA cookie 时，将会进行怎样的处理呢？服务器验证 cookie 并得知该 cookie 属于 Bland —— 一位已经登录的用户。服务器就可以允许 Jim Bland 对这台服务器上进行适当的访问。
总之，确定在什么时候应该随同 HTTP 通信一起发出该 LTPA cookie 是浏览器的任务（参见图 3）。
设想 Jim Bland 浏览到一个不在 spies.com DNS 域中的 URL。例如，浏览到 cia.gov 域中的 URL（他也许想去中央情报局找份更有意思的工作）。在这种情况下，浏览器就不能发送 LTPA cookie，因为该 cookie 不适用于 cia.gov 域，它仅适用于 spies.com 域。浏览器只是不将 cookie 发送到 cia.gov 目标，因此接收服务器就不知道用户是谁。在允许访问前，cia.gov 服务器可能将提示 Bland 输入他的用户名和口令。
图 3. 浏览器只将 LTPA cookie 发送到 spies.com 域中的服务器
在图 3 中：
A. Bland 已经登录。浏览器自动发送 LTPA cookie 以允许他访问 spycentral.spies.com 域中的 URL。
B. Bland 浏览 spies.com DNS 域中另一台服务器上的 URL，由于浏览器发送了 LTPA cookie 而获得了访问权限。
C. 浏览器无法将 LTPA cookie 发送到 www.cia.gov，由于其不在匹配的 DNS 域中，因此在允许访问前，cia.gov 服务器必须提示 Bland 输入用户名和口令进行登录。
SSO 的根本出发点是为方便用户，但是如果它不安全，那么它的意义就不大了。安全性极为重要，尤其是对于 TGSA 这种有很多敌人的机构。LTPA cookie 是安全的，因为在创建它时进行了安全加密。服务器在创建 LTPA cookie 时，使用一组加密密钥。加密密钥用于对 cookie 进行编码，编码后的 cookie 传送到用户浏览器，除非有加密密钥，否则无法对 cookie 进行解码。同时还使用加密密钥验证 cookie，例如可以验证 cookie 的完整性和随时检测 cookie 是否被篡改。SSO 环境中的所有服务器必须共享同一加密密钥。当 SSO 服务器接收到 HTTP 请求并发现其中包含 LTPA cookie 时，服务器使用它共享的加密密钥副本验证 cookie，有效 cookie 中的信息使服务器能够识别登录的用户（例如 Jim Bland）。
SSO 服务器使用的安全加密确保没有任何伪造 cookie 的机会。设想 Bland 的敌人 Dr. Notnow 试图创建他自己的 SSO cookie，希望以此入侵 SSO 服务器。Dr. Notnow 不会成功入侵 SSO 服务器，因为他没有加密密钥。来自 Dr. Notnow 的伪造的 cookie 将被忽略，因为该 cookie 不会通过验证。
在 WebSphere Portal 环境中，LTPA 加密密钥通常在配置 SSO 时由 WebSphere 创建。管理员可以将密钥导出到文件中，然后转移该文件到其他的 SSO 服务器（例如，Domino），这样可以在那里导入密钥。显而易见，您应该非常小心地处理这个密钥文件，并将所有副本保护好（如果不进行视网膜扫描）！
好，现在应该确信 SSO 的安全性是内置的（有关如何正确部署安全的 SSO 环境的其他技巧，请参阅 这个副文件）。现在，让我回过头来探讨在编码的 cookie 内部有什么。这里有更多关于 Jim Bland 登录时所发生的事的详细信息。首先，他提供了他的用户名 jb013 和他的口令。接着登录服务器在目录中查找用户 jb013。在目录中，设想查找到了带有惟一名称 uid=jb013,ou=secret,dc=spies,dc=com 的用户条目。验证该用户的口令后，现在服务器可以通过这个惟一名称识别这个用户。这个惟一名称被写入到生成的 LTPA cookie 中并发送到浏览器。浏览器随同 HTTP 通信一起发送该 cookie。接下来会发生什么呢？当浏览到 SSO 环境中的 URL 时，SSO 接收到该 cookie 并使用加密密钥解码和验证它。SSO 服务器将发现在 cookie 内有这个用户的名称 uid=jb013,ou=secret,dc=spies,dc=com。SSO 服务器基于 LTPA cookie 中提供的名称标识该用户（参见图 4）。
图 4. 在编码的 cookie 内部
在图 4 中：
A. 提示 Bland 登录，因此他输入用户名 jb013 和口令。
B. 服务器在目录中查找用户 jb013，找到一条匹配的用户记录，并根据该记录来验证 Bland 的口令。
C. Bland 现在已经登录了。服务器向浏览器发送包含 Bland 的专有名称的 LTPA cookie。
在所有 SSO 组件都使用一个目录的环境中，LTPA cookie 中的名称足以确切地标识用户。但是，在有多个目录的更复杂的环境中，如果为某个单一用户（例如 Bland）在这些目录中使用多个名称格式，就会引起问题。假设使用了两个目录：Microsoft 的 Active Directory 和 IBM Lotus Domino Directory。当 Bland 的 Active Directory 专有名称与他定义的 Domino 专有名称不同时就会发生问题。当用户具有一个以上的名称时，就会出现问题，因为 LTPA cookie 包含且仅包含一个名称以标识已登录的用户。LTPA cookie 中包括的用户名称可能是接收服务器对该用户所知道的惟一信息。如果接收服务器在识别 LTPA cookie 中的名称时遇到麻烦，将会导致 SSO 令人沮丧地失败。
  |
|
TGSA 的 IT 管理员很羡慕 Jim Bland 的任务那么轻松 —— 要是 IT 工作也是这样“可完成的”就好了。对于 IT 管理员来说，当整个宇宙需要控制时，这个世界就不够了。公司 IT 基础设施很少根据主要的计划来进行组织，通常简直就是一团糟。许多组织的最终目标是拥有一个包含所有公司用户的单一目录，但是更常见的情况是公司结构内会具有至少两个（通常更多）目录。给管理员带来混乱的多身份口令验证问题，需要他们找到可行的解决方案。
那么为什么会有一个以上的目录？大多数人都知道，不同的应用程序有不同的目录要求。组织中的多个应用程序环境会导致长期填充不同的用户存储库，例如，一个具有现有 WebSphere Portal Application 环境的公司，已经在 LDAP 目录中创建了用户和组，并且具有使用 Domino Directory 的 IBM Sametime 环境。Domino 应用程序的访问控制机制（ACL）和执行控制机制（ECL）通常很复杂，难于更改。这时，要基于正在使用中的特定目录重新组织或复制访问控制列表将是一个非常困难、耗费时间、经费上也不允许的方案。最后，在不断变更的环境中，公司合并和开拓新业务（甚至政府政变）通常会迫使您（管理员）一次又一次地将新目录合并到现有的基础设施中。
好的秘密工作人员，像 Jim Bland，总是有一个逃跑计划，TSGA IT 部门也是这样。在将要举出的例子中，探讨了 IBM 如何帮助 Bland 的高级 VM 和她的 IT 管理员成功地集成他们的多目录、多身份环境。他们的基础设施需要使用两个目录。WebSphere Portal Server（WPS）和 WebSphere Application Server（WAS）的 TSGA 实施被配置为使用 LDAP IBM Directory Server（ITDS）；Domino Web Access portlets、Sametime 和 Quickplace 等应用程序提供的多协作环境要求使用 Domino Directory。TSGA 代理同时位于这两个目录中。
理解多目录、多身份场景对于 TSGA 是关键，因为 VM 的计划是使用全部的 IBM 协作产品，包括 Domino、Portal applications 和 IBM Workplace Collaboration Services，而不会引起很大的变化。VM 要求在部署 IBM 产品、解决方案和技术系列时实现有效的 SSO，无缝地帮助 Bland 执行任务。
正如前面所提到的，名称在 SSO 环境中非常关键。Jim Bland 确实只有一个名称，但是在间谍活动环境和 TSGA IT 基础设施中，会有多重验证。在 TSGA 总部，已经使用不同的目录基础设施部署了几个应用程序，因此 Bland 具有多个身份，每个身份都是在发布目录的架构基础上进行格式化的。例如，IBM Tivoli Directory Server（ITDS）中 Bland 的专有名称（DN）在层次和语法上都不同于他的 Domino 专有名称：
| LDAP 格式的身份（ITDS） | Domino 格式的身份 |
| uid=jb013,ou=secret,dc=spies,dc=com | cn=Jim Bland/ou=secret/o=spies |
请记住，一旦用户登录后，SSO 服务器和应用程序对用户进行识别非常重要。当 Bland 在其浏览器中输入 WebSphere URL 时，系统会提示他输入用户名和口令进行登录。通常会有次数限制，Bland 输入他的惟一标识符 jb013。WebSphere 应用服务器通过在 ITDS 服务器中查询 Bland 的名称对他进行验证，并对所输入的口令进行验证。当他的名称通过验证后，Bland 就可以在他的浏览器中访问 WebSphere Portal Server 内容（参见图 5）。
图 5. Portal 登录身份
LTPA cookie 现在包含 Bland 的 LDAP 身份：uid=jb013,ou=secret,dc=spies,dc=com。这即是其 Portal 登录身份。
Jim 现在决定检查其电子邮件（他在等待对 CIA 工作搜索查询的回复）并切换到其 Domino Web Access portlet（参见图 5）。通过 HTTP，LTPA 令牌被发送给 Domino Web Access 服务器，服务器然后搜索 Domino 目录以验证其身份（身份验证），并根据其身份，服务器将决定是否允许他使用 Domino Web Access 资源（授权）。但是 LTPA 令牌包含他的 Portal 应用程序身份。Bland 能否获得访问权？
Bland 真的被授予访问权，并且他的 portal 身份 jb013 被映射到 Domino Web Access portlet 中的 Domino 身份 Jim Bland。但是，TSGA 的集成应用环境是如何处理名称映射的呢？