案例研究 1：IBM Intranet Password External (IIPx)

    案例研究 1 讨论用于外部业务合作伙伴应用程序的标识管理。

业务上下文

    随着 IBM 内部 Web 应用程序的增多，IBM 员工必须管理多个 ID 和密码，因为每个早期应用程序都开发了自己独有的身份验证机制。20 世纪 90 年代中期后，我们发现了需要为所有 IBM 内部 Web 应用程序采用单一的全球身份验证机制，从而为每个 IBM 员工提供单一的 ID 和密码凭据。IBM Intranet Password (IIP) 功能是作为公用解决方案开发和部署的，目的是支持内部应用程序的标识管理。不过，IIP 为每个 IBM 员工实现单个 ID 和密码的目标当时并没有完全实现，因为存在大量 IBM 员工用于进行其日常 IBM 相关工作的 IBM 业务合作伙伴网站和应用程序。这些外部的第三方供应商网站包括外包旅行预定、管理调查、退休福利与规划、辅导计划和 IBM 书店等。应用程序提供者对于其每个系统采用了独有的 ID 和密码方案，从而导致 IBM 员工仍然需要使用多个 ID 和密码才能访问他们的网站。

挑战

    当 IBM 员工使用合作伙伴提供的业务应用程序时，他们需要使用每个应用程序实现的不同身份验证方案。每个业务合作伙伴通常为其网站的用户创建用户身份验证凭据（通常只是 ID 与密码的组合），各自建立了有效密码和密码过期的规则。IBM 员工在执行与 IBM 业务相关的职能时，会浪费大量的时间记录和重置这些外部网站上的多个 ID 和密码。

    由于各自采用了独特的身份验证系统，IBM 合作伙伴必须提供足够的帮助中心覆盖，以处理 IBM 员工要求提供凭据协助的呼叫。此外，与身份验证管理解决方案和业务规则相关的开销成本必须通过 IBM 的合同费用得到补偿。

    对跨多个合作伙伴应用程序的身份验证的需求变得非常明显了，需要能够借此提高员工的满意度和减少成本。为了管理 IBM 员工凭据的身份验证，有些业务合作伙伴要求提供 IBM 员工 LDAP 目录的副本并定期进行更新。为了维护 IBM 内部网络的完整性以及保护隐私，IBM 无法在 IBM 外部共享员工数据或允许合作伙伴访问 IBM 内部网络来直接使用内部 LDAP 实例。问题的任何解决方案都受到已经存在的安全系统的约束。

    需要能确保满足以下约束的解决方案：

• 对现有应用程序的影响最小。要求每个业务合作伙伴执行实现新解决方案的主要工作并不现实。
  
  
• 仍然可以使用这些应用程序的现有 ID 和密码。另一个目标是尽可能让 IBM 员工方便地进行过渡。
  
  
• 对业务合作伙伴而言，该解决方案的实现需要相对简单。解决方案必须安全，但业务合作伙伴对需要自己进行大量工作和需要持续进行密码维护的解决方案不感兴趣。

基于 SOA 的解决方案

    所得到的采用 SOA 的解决方案名为 IIPx，如图 1 中所示。IIPx 是一个身份验证实用工具，可使用 IBM 内部网 ID 和密码获得对外部 Web 应用程序的访问。IIPx 基于早期部署的用于提供内部应用程序的员工标识管理的 IIP 解决方案的基础。

图 1. IIPx 体系结构概述

    外部应用程序使用 IBM 提供的 Web 服务来验证 IBM 员工的身份。此服务对令牌（经过数字签名的 XML 文档）进行验证。IIPx 会在 IBM 内部 IIP 对员工进行了身份验证后创建该令牌。IIPx 将使用内部目录执行本地 LDAP 身份验证。对用户的凭据进行了内部身份验证后，其浏览器将使用令牌重定向到外部站点。

    以下是图 1 中所示的典型 IIPx 登录会话的详细描述。描述中使用的数字与图中的数字对应：

1. IBM 员工连接到业务合作伙伴网站。IBM 员工通过包含供应商标识代码的链接导航到 IIPx 登录页。这在 IBM 内部网络（用 w3 指代）进行。此链接 通常为到 IBM 内 IIPx 登录页的按钮或 URL。
2. 身份验证通过 w3 进行。
   1. 员工输入 IIP 登录凭据。此为 IBM 员工正常的内部 ID 和密码。
   2. IIPx 服务器将会像处理任何内部 IBM 员工的凭据一样验证 IIP 登录。
   3. IIPx 服务器创建包含基本员工信息的 XML 文档，该信息从内部 IBM 员工目录（在 IBM 内部称为蓝页）检索。此文档传递给供应商，以提供关于访问网站的员工的信息。
   4. IIPx 服务器为 XML 文档创建数字签名。此数字签名基于公用 IBM 主控密钥，此密钥仅在 IBM 内可用。
   5. IIPx 服务器生成 HTTP 重定向 URL，其中包含已编码的 XML 文档和签名，服务器会将此 URL 返回给员工桌面上的客户机浏览器。
3. 传递身份验证令牌。
   1. 客户机浏览器根据重定向 URL 导航到第三方网站。
   2. 第三方从 URL 的变量中检索 XML 文档和签名。
   3. 第三方站点将签名和文档传递给 IBM 的 IIPx Web 服务（SOAP 接口）。这个 IBM 承载的服务在外部网上向业务合作伙伴提供。
   4. IBM IIPx 外部 Web 服务验证文档和签名的匹配情况。这可确保密钥匹配，即来自 IBM 的登录和数据是正确的。服务返回确定信息。
   5. 第三方站点建立用户会话，信息量通过供应商的站点继续。

    为了管理 IIPx 的实际部署，使用了增量式加载的概念。其理念是，在部署新功能的同时应用程序可以继续操作其现有身份验证功能。在较短的过渡期间，可以同时使用新旧两种 IIPx 身份验证。只有经过完全测试，才能关闭之前的身份验证。

    增量式加载还保证所有应用程序不存在统一的退役日期。这样就使得业务合作伙伴能够确定对其应用程序和自己的工作负载可行的退役计划。增量式加载还能给 IBM 员工带来好处，让他们有更多的时间注意到对所有用户推出的更改。

业务成果

    IIPx 解决方案很快被大家接受，并从合作伙伴和员工收到了大量积极的反馈。这个新身份验证功能的引入几乎对员工是透明的。通过实现此服务，IBM 实现了业务灵活性，可方便地添加新员工用户和从已建立的 IBM 机制内方便地管理 ID 和密码。IBM 员工现在获得了更好的外部网体验，只需要记住一个 ID 和密码，而不需要执行特殊的步骤来调用这些由供应商进行管理的外部应用程序网站。IBM 业务合作伙伴通过使用此服务节省了大量成本。业务合作伙伴并不需要为用户设置 ID 和密码，合作伙伴也不需要维护这些密码系统。

非常好的实践及获得的经验教训

    IIPx 的实现对 IIP 实现了重用，而后者是一个经过了验证的 IIP 服务。此重用清楚地表明了 SOA 的灵活性。IIP 在内部为 IBM 员工实现，用以访问内部应用程序。此身份验证模型和 Web 服务允许从 IBM 外部使用此功能，从而在不影响 IBM 员工目录的安全性和完整性前提下获得此功能的好处。

    尽管 IBM 业务合作伙伴很快接受了此解决方案，但仍然需要花一定的时间对其各个解决方案进行转换。由于其计划、资源可用性和其他业务约束会导致一些延迟。不过，增量实现的概念让 IBM 业务合作伙伴能够在计划中定义可满足其需求的单独的无干扰转换过程。最终我们按应用程序逐个引入新功能，项目并没有具体的时间限制。

    使用 Web 服务的 SOA 接口提供了用于员工凭据的身份验证的安全而准确的解决方案，不仅在整个企业内，而且还跨多个外部合作伙伴。此接口很难被欺骗，因为安全凭据传递给业务合作伙伴的方式非常安全。凭据是作为参数在 URL 上传递的。因此，业务合作伙伴将使用 IBM 外部网 Web 服务，实际上是让 IBM 验证这些凭据。此匹配让员工和业务合作伙伴都相信能正确标识员工并应向其提供被授权的功能和数据。

    IIPx 团队还对遗留应用程序使用了增量式加载，以实现无缝过渡。有些应用程序在采用 IIPx 前已经具有 ID 和密码系统。这些合作伙伴可以在开发完成时过渡到此方法，甚至允许在退役期结束之前同时使用新旧两种形式的身份验证。

    最后，IIPx 非常成功，因为它并不要求所有 IBM 员工仅为了访问供应商管理的 IBM 功能而获取新 ID 和密码。大部分 IBM 员工可能并不会认识到这些应用程序在 IBM 外的环境中运行，因为到业务合作伙伴的转换几乎是无缝的。这种几乎透明的新功能实现或迁移是大部分项目的目标，但通常却没有实现。