【IT168 SOA文档】各个案例研究说明了IBM如何处理各种业务挑战（在其中利用了 SOA 来处理这些挑战），通过这些案例研究，可以帮助您了解如何使用 SOA 来处理您自己的业务挑战。案例研究1 讨论用于外部业务合作伙伴应用程序的 IBM 员工标识管理案例研究2讨论 IBM 客户与业务合作伙伴标识管理及 IBM 网站用户的授权。我们专门精选了这些案例研究来代表利用 SOA 解决的各种业务挑战。每个案例研究都说明了启用 SOA 的解决方案如何通过对流程和业务规则进行更广、更方便且更便宜（甚至跨组织边界）的更改，来帮助实现所需的业务灵活性。
案例研究 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 的解决方案名为 IIPx，如图 1 中所示。IIPx 是一个身份验证实用工具，可使用 IBM 内部网 ID 和密码获得对外部 Web 应用程序的访问。IIPx 基于早期部署的用于提供内部应用程序的员工标识管理的 IIP 解决方案的基础。
外部应用程序使用 IBM 提供的 Web 服务来验证 IBM 员工的身份。此服务对令牌（经过数字签名的 XML 文档）进行验证。IIPx 会在 IBM 内部 IIP 对员工进行了身份验证后创建该令牌。IIPx 将使用内部目录执行本地 LDAP 身份验证。对用户的凭据进行了内部身份验证后，其浏览器将使用令牌重定向到外部站点。
以下是图 1 中所示的典型 IIPx 登录会话的详细描述。描述中使用的数字与图中的数字对应：
- IBM 员工连接到业务合作伙伴网站。IBM 员工通过包含供应商标识代码的链接导航到 IIPx 登录页。这在 IBM 内部网络（用 w3 指代）进行。此链接 通常为到 IBM 内 IIPx 登录页的按钮或 URL。
- 身份验证通过 w3 进行。
- 员工输入 IIP 登录凭据。此为 IBM 员工正常的内部 ID 和密码。
- IIPx 服务器将会像处理任何内部 IBM 员工的凭据一样验证 IIP 登录。
- IIPx 服务器创建包含基本员工信息的 XML 文档，该信息从内部 IBM 员工目录（在 IBM 内部称为蓝页）检索。此文档传递给供应商，以提供关于访问网站的员工的信息。
- IIPx 服务器为 XML 文档创建数字签名。此数字签名基于公用 IBM 主控密钥，此密钥仅在 IBM 内可用。
- IIPx 服务器生成 HTTP 重定向 URL，其中包含已编码的 XML 文档和签名，服务器会将此 URL 返回给员工桌面上的客户机浏览器。
- 传递身份验证令牌。
- 客户机浏览器根据重定向 URL 导航到第三方网站。
- 第三方从 URL 的变量中检索 XML 文档和签名。
- 第三方站点将签名和文档传递给 IBM 的 IIPx Web 服务（SOAP 接口）。这个 IBM 承载的服务在外部网上向业务合作伙伴提供。
- IBM IIPx 外部 Web 服务验证文档和签名的匹配情况。这可确保密钥匹配，即来自 IBM 的登录和数据是正确的。服务返回确定信息。
- 第三方站点建立用户会话，信息量通过供应商的站点继续。
为了管理 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 外的环境中运行，因为到业务合作伙伴的转换几乎是无缝的。这种几乎透明的新功能实现或迁移是大部分项目的目标，但通常却没有实现。
案例研究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 工具是非常关键的一步。所有外部网站的开发项目都采用一致的方法，以确保正确标识其对外的网站应用程序的用户。
