案例研究2：Customer IBM Web Identify——IBM 网站和相关功能的用户的标识管理与授权
www.ibm.com 域是 IBM 用于提供信息和与客户及业务合作伙伴进行交互的一组网站和相关应用程序。除了直接电子商务与招聘网站外，此域还包括业务合作伙伴可以在其中找到的关于制造、采购或配送的信息门户。
各种支持客户和业务合作伙伴的外部 IBM 网站要求其用户对每个网站采用独有的用户凭据（用户 ID 和密码）。要注册，客户和业务合作伙伴必须向每个外部站点提交实际上是多余的基本注册信息，如姓名、地址、电子邮件地址。尽管为独立的站点域（如 Software Developer Support）部署了一些公用身份验证和注册解决方案，用户仍然需要维护多个凭据才能访问各种 IBM 网站。此外，各个 Web 应用程序间还存在资源浪费，每个应用程序开发、部署和维护自己的用户 ID 和密码身份验证功能。这是造成客户不满意的原因，需要使用针对整个 IBM 企业的公共 IT 解决方案加以处理，与 (IBM Intranet Password) 解决方案类似。
为了确保安全地保护 ibm.com domain 中的信息，并仅交付给授权的人员，关键功能中始终包括身份验证系统。不过，随着 Internet 的发展，各个 IBM Web 应用程序开发团队在创建应用程序供业务合作伙伴和客户使用的过程中也创建了很多不同的密码模式。
当时并不存在针对外部用户的中央目录；因此，IBM Web 应用程序无法共享关于其用户的标识和注册信息。IBM 为 IBM 客户和合作伙伴部署的每个网页或应用程序都必须收集自己的身份验证信息。此外，每个应用程序要建立不同的用户 ID 和密码要求（如密码允许的字符数和类型）。这对用户来说非常费时，安装新应用程序的时间会过长。
需要公用的企业级解决方案来为每个客户和业务合作伙伴提供单一用户 ID 和密码，以登录到 ibm.com 域的任何 Web 应用程序。此解决方案还必须支持每个应用程序所有者分开管理应用程序访问权限。
由于很多应用程序具有自己的身份验证解决方案，因此业务合作伙伴已经具有了自己的注册用户。一个目标是将其中用户尽可能多地迁移到新系统中，并接纳已经存在的不同用户 ID 和密码的格式。理想情况下，外部用户不应必须注册，甚至不应注意到是新系统在后台管理身份验证。需要使用所得到 Web Identify 服务来在一个解决方案中支持所有这些需求。
Web Identify (WI) 系统向 ibm.com 应用程序提供关于用户的信息。该系统将用户概要信息收集在中央数据存储区中，并通过 Web 服务接口向外提供。概要信息包括标准元素，如用户名、地址、内容首选项、所感兴趣的领域以及营销权限等。此外，它还提供应用程序特定的数据。通过在集中的位置收集概要信息，可减少 ibm.com 的零碎视图，从而使得将来的 Web 个性化成为可能。
WI 还提供了对身份验证服务的访问，允许应用程序对用户进行身份验证，并管理组与角色。
最后，应用程序可以通过 WI 系统共享会话信息，从而消除通过 URL 参数或 Cookie 传递信息的需求。
Web Identify 具有加载流程，可供应用程序用于描述与 Web Identify 工具中的应用程序关联的角色和权限。Web Identity 提供了基于 LDAP 的目录服务来支持应用程序管理员将用户分配到角色，以供应用程序用于管理用户授权。
使用 Web Identify 功能的步骤通过面向服务 (SOAP) 的接口执行：
- 加载应用程序。
- 设置用户 ID 和概要。
- 用户登录到应用程序。
加载应用程序
此部分描述如何在 WI 中加载应用程序，以及批准用户访问请求的持续工作。每个应用程序分配一个或多个管理员来控制用户对其功能的访问。对于某些应用程序，管理员是负责管理其各自站点的 IBM 员工，在其他情况下，管理员是合作伙伴，负责管理公司员工的授权，以开发与合作伙伴进行交互的 IBM 网站中的应用程序。管理员与 WI 团队合作定义应用程序，包括应该对特定的应用程序设置哪些角色和访问级别。管理员将检查新用户的访问请求，并将其分配到与应用程序关联的特定角色。这样可允许用户获得对其需要使用的各种 IBM 应用程序的访问权限。
设置用户 ID 和概要
从外部用户的角度而言，WI 网站允许他们为自己创建用户 ID 和密码。这之后，用户独立于其访问的应用程序维护其用户 ID 和密码。此外，网站还允许用户注册和创建基本信息概要（如姓名、地址和电子邮件地址），并声明其可能感兴趣的站点部分或 IBM 服务/产品。最初的时候，用户 ID 并不与任何特定应用程序领域相关，且没有任何权限。为了获得访问权限，用户将基于自己的需要请求对特定应用程序的访问，包括特定角色或访问级别。经过批准后，用户可以登录到特定的应用程序，并使用这些功能。
用户登录到应用程序
以下是图 2 中所示的典型会话的描述。描述中的内容与图中从左到右的功能对应。
- 用户可以访问 ibm.com 系统的功能，并使用 Tivoli Access Manager (TAM) 进行身份验证。TAM 对用户执行身份验证功能，将接受或拒绝登录。
- 用户的凭据通过身份验证后，会将会话传递给 WI Adopting Applications，以执行相应的功能。
- WI Adopting Applications 能够通过一系列调用和 Web 服务访问用户安全设置、概要和会话信息，从而使应用程序能够获取关于用户的特定信息。
WI 提供用于在用户启动会话后检索用户的凭据和概要信息的服务。这些服务允许应用程序检索用户的基本注册概要信息以及向用户分配的应用程序和角色。这就允许应用程序收集关于每个用户的更为详细的信息来在任何 ibm.com 网站上自定义用户会话。
表 1 显示了其中一些可用服务。
表 1. Web Identity 功能
| WI 功能 | 描述 |
|---|---|
| authenticateUser | 对用户的凭据进行身份验证 |
| addToGroup | 让用户成为组的成员 |
| isGroupMember | 确定用户是否是组的成员 |
| removeFromGroup | 从组删除用户 |
| createIdMapping | 将 IR ID 与另一个 ID 关联。用于提供迁移辅助 |
| getIdMapping | 获取 IR ID 的关联 ID |
| removeIdMapping | 删除 ID 关联 |
| addToRole | 向用户分配角色 |
| isRoleMember | 确定用户是否在给定的角色中 |
| removeFromRole | 从用户删除角色 |
| resetPassword | 重置用户的密码 |
WI 最初在 1999 年部署，已成功用于 ibm.com 应用程序。现有应用程序逐渐将其身份验证与注册功能过渡到使用 WI。2003 年将 WI 正式定义为了 IBM 公司的外部身份验证标准，此后我们加速了此迁移工作。
通过使用 WI 提高了客户满意度和效率，对应用程序使用者和应用程序开发人员及管理员也是如此。使用 Web Identity 系统的客户、业务合作伙伴和开发人员对这个改进予以了认可。
目前，可通过 ibm.com 域内 1000 多个网站访问的 200 多个应用程序都在使用 WI。Web Identity 内建立了超过 350 万 IBM 客户、合作伙伴和提供商 ID。
从 1999 年开始，使用 Web Identity 所带来的累计应用程序成本节省估计已达 4700 万美元。在此期间，IBM 已经在 Web Identity 的开发与部署方面投入了约 1180 万美元。
在 Web Identity 的开发与部署期间获得的一些主要经验教训有：
- 概念验证（Proof of Concept，PoC）对应用程序的性能评估至关重要。WI 团队注意到了这一点，成功地使用了 PoC 来了解和解决 WI 的原始性能问题。早期进行 PoC 对 Web Identity 的初始开发和部署有莫大的好处。
- WI 团队认识到，应用程序范围的扩大可能具有潜在困难，因此将大量的精力放在了有效扩大流程的定义和文档编制工作上，其中包括处理现有应用程序的资金投入问题。
- WI 首次发布时，已经存在很多用户 ID 和密码系统。为了尽可能减少对应用程序和用户的影响，我们将已有的凭据加载到了 Web Identity 中，从而允许用户保留其原始凭据，而无需进行修改。尽管并非总是能够这样做，但这样的确为很多用户提供了无缝过渡。
在 ibm.com Web 域中首次使用之后，WI 被确定为正式的 IBM 内部开发标准。这对确保在 IBM 内全面采用 WI 工具是非常关键的一步。所有外部网站的开发项目都采用一致的方法，以确保正确标识其对外的网站应用程序的用户。
