安全的、面向服务的体系结构BizTalk Server 2004 在构建灵活的 SOA 方面发挥至关重要的作用 |
|
http://www.microsoft.com/china/biztalk/roadshow/developer/d6.asp |
|
2004 年 3 月 11 日 作者：David Regan BizTalk Server 2004 有望成为实现面向服务的体系结构 (SOA) 的无价工具：助反应敏捷的企业能够快速响应瞬息万变的业务需求。BizTalk 是一种基于 XSD 和 XML 构建的企业应用程序集成产品，这意味着它是通过 Web 服务构建的针对 SOA 的自然集成工具。 然而，Web 服务技术才刚刚成熟 – 只在最近才推出了相应的产品，来实施旨在保护 Web 服务安全的 WS-Security 标准。Microsoft 提供了一款性能卓越的产品 Web Services Enhancements 2.0 (WSE)，用于实施 WS-Security 和相关的 WS-Policy 标准（当然还有其他标准）。 如果没有安全的 Web 服务，面向服务的体系结构就无法广泛实施 – 它们将始终被指责为概念证明的地狱。本文讨论将 BizTalk 与 WSE 结合起来以便构建安全的 SOA 的技术。 面向服务的体系结构 我们按孤立的功能单元构建传统的应用程序，例如，一个记帐系统或人力资源管理软件包。现代应用程序按多个体系架构分层构建，以便提高可维护性或可靠性，但是这种方法无法解决将孤立的应用程序集成到一个有机联系的企业信息体系结构中的问题。图 1 说明三个孤立的三层应用程序如何通过有限的应用程序间通信结合起来形成简单企业的 IT 基础架构。 传统的方法会带来许多问题：有限的应用程序间通信和僵化的信息体系架构。这些问题正是面向服务的体系结构想要解决的。 SOA 着眼于定义使用和生产业务文件的合同，而不是创建用于操纵数据的客户机/服务器应用程序。SOA 利用广泛接受的标准（例如 WSDL、XML、XSD、UDDI 和 HTTP）使服务在网络中可用，并允许应用程序寻找和绑定活动服务（通过 UDDI 和 WSDL），以创建松散耦合的企业流程。 与纵向的功能单元相反，SOA 允许这些单元针对某个特定业务范围或合作伙伴范围分解成制作、使用业务文档的服务组。传统的分层应用程序可以被充分利用跨越多个业务范围的服务的流程所取代。图 2 说明以往孤立的应用程序堆栈如何分解为服务组，以及如何构建新服务以协调与低级别服务的交互作用。请注意如何通过在 SOA 中的任何一个级别上添加一个显示层来构建一个最终用户应用程序。 图 2 介绍了一个新技术层 – 业务流程基础架构。这就是 BizTalk 在 SOA 中的作用。您可以构建一个没有业务流程（级别较高的服务可以通过硬编码逻辑来管理级别较低的交互）的 SOA，但是业务流程允许 SOA 迅速调整以满足不断变化的业务需求。在这个意义上，SOA 支持创建“反应敏捷的企业”的目标。 BizTalk Server 2004 是用于构建反应灵敏的 SOA 的非常灵活和强大的工具。它提供使用 Web 服务并将其业务流程公开为 Web 服务显示的工具 – 通过这种方法通过小服务来构建更大的服务。而且，利用它的适配器框架，可以为旧版应用程序和数据源创建 Web 服务接口。只需通过简单的拖放业务流程设计器和图形数据映射工具，便可以完成所有这些工作。 虽然 BizTalk 是创建反应灵敏的 SOA 的理想技术，但我们不能忽视这个事实：目前的 SOA 将构建于 Web 服务技术之上，而且我们必须能够在这个基础上安全地进行构建。 Web 服务技术正在走向成熟，而且对路由、寻址功能支持和事务处理支持还处于萌芽阶段。但是，Web 服务安全性现在已经达到了使该技术适合实践使用的成熟水平。我们需要解决的问题是如何利用它来构建 SOA，然后如何将 Web 服务安全性与 BizTalk Server 的使用相结合。 Web 服务安全性 WS-Security 和 WS-Policy 策略标准包含的 Web 服务安全性是扩展 Web 服务技术的 OASIS 标准联盟规范中最成熟的部分。WS-Security 是向 SOAP 信封标头中添加安全信息的规范，可以支持发件人的识别、消息签名和加密。WS-Policy 是要求已接收的 SOAP 信封应当具有哪些特征的规范。特别是，WS-Policy 提供了一种要求特定的 WS-Security 标准的机制。 Microsoft 提供名为 Web Service Extensions 2.0 (WSE) 的产品，该产品实施 WS-Security 和 WS-Policy 标准。WSE 支持用户/密码和 Kerberos 标识、X509 数字签名和 X509 或对称密钥加密。而且，WSE 是一个可扩展系统，可以在其中将自定义的安全令牌处理器配置到消息处理管道中。除了支持 WS-Security 和 WS-Policy 外，WSE 还支持 WS-Routing、WS-Trust 和 WS-SecureConversation。 WS-Security 提供确保端到端安全的工具，而不是仅提供简单的点对点安全的工具。在安全的网站中广泛使用的安全套接字层 (SSL) 协议就是点对点安全的一个例子。SSL 的工作原理是：使用非对称密钥技术对通过网络发送的所有数据进行加密。对于中间路由器或防火墙，它无法处理数据，而是盲目地将数据转发到指定的端点。事实上，由于可以使用 SSL 通过防火墙建立不透明的通信信道，这种点对点安全性使许多公司的企业内部网变得不安全。 随着 SOA 技术的成熟，对复杂的 SOAP 信封中间处理的要求越来越多（例如，WS-Routing、WS-Transaction 等）。为支持 SOAP 处理中间媒介并启用端到端安全性，WS-Security 标准指定如何将安全令牌添加到 SOAP 标头，而不隐藏其他标头信息，例如路由或寻址信息。 WS-Security 最重要的方面是能够使用非对称密钥对邮件进行签名和加密。WSE 通过使用 X509 证书来支持这一功能。 对邮件进行数字签名是一个在邮件正文中添加元数据的过程，这可以证明该邮件是由有待确定的发件人发送的，而且邮件在发送过程中没有被破坏。对邮件进行签名有多种可供选择的方法，但基本过程如下所示（参见图 3）。邮件的发件人从证书颁发机构活动非对称密钥对。该密钥对由公钥和私钥组成。邮件发件人将公钥分发给想要将其签名邮件发送到的所有收件人。 发件人然后计算邮件正文的哈希值，并使用私钥为该哈希值加密。经过加密的哈希值与邮件正文一起构成发送给目标收件人的数字签名邮件。 收件人使用发件人提供的公钥解密签名来检索哈希值。收件人然后重新计算邮件正文的哈希值，并将其与发送的哈希值进行比较。如果两个哈希值相匹配，那么收件人可以确定以下两个事实： 首先，期望的发件人发送了邮件（只有发件人能够使用私钥对哈希值加密），其次，邮件在传输过程中没有被篡改（任何篡改将导致更改计算过的哈希值）。 利用非对称密钥加密邮件（参见图 4）使用类似的过程，但在这种情况下，发件人利用收件人的公钥对邮件进行加密。密钥元数据作为标头添加到 SOAP 标头中，然后用 SOAP 信封发送经过加密的邮件正文。 收件人在收到邮件时将使用私钥解密邮件。在这种方案中，收件人向希望与其安全通信的所有发件人分发公钥。 注意： 为了对邮件进行数字签名，发件人使用自己的私钥，而收件人使用发件人提供的公钥。反过来，发件人使用收件人提供的公钥进行加密，而收件人使用它们的私钥进行解密。这种在公钥和私钥的使用上存在的相反做法使双向签名和加密邮件的情况屡见不鲜。 除了签名和加密邮件外，WS-Security 指定（并且 WSE 支持）SOAP 标头中的安全令牌，这些令牌使用用户/密码或 Kerberos 票证来识别邮件发件人。该标准还支持指定邮件有效期的令牌，以避免遭受重复攻击。 WSE 是实施 WS-Security 标准的强大、灵活的工具，可以和 BizTalk 业务流程集成以公开为 Web 服务。 将 BizTalk 业务流程公开为安全服务 BizTalk 业务流程通过端口发送和接收数据。在设计时候或部署期间可以配置端口带有处理管道和传输适配器。管道负责编码/解码和组装/分解邮件，以及验证和参与方解析。适配器负责与所选的邮件传输机制进行通信。对于简单的适配器，例如提供的文件适配器，很容易理解这种方法。文件适配器能够监视目录或子目录，查找与所配置的模式相匹配的新文件或修改过的文件，并处理已更改文件的内容。 将业务流程公开为 Web 服务则略有不同。所提供的 SOAP 适配器不是公开的 Web 服务的端点。与文件适配器进行类比，您可以想像 SOAP 适配器将监听传入的 HTTP 请求，但这明显与正在由 Internet 信息服务 (IIS) 托管的其他 Web 服务和 Web 应用程序冲突。结果，SOAP 适配器依靠向导生成的 ASP.NET Web 服务占位程序来公开 Web 服务界面，这反过来会调用 SOAP 适配器。BizTalk Web 服务发布向导实现这一机制的方法是创建从 Microsoft.BizTalk .ServerProxy 类中派生出来的 Web 服务代理（例如，.asmx 文件和关联的隐藏代码的文件），而该类反过来是从标准的 System.Web.Services.WebService 类中派生的。BizTalk 服务器代理创建 BizTalk 消息，并将所有 SOAP 标头添加到消息上下文中，然后调用该 SOAP 适配器。 图 5 说明了一起把业务流程公开为一项 Web 服务的组件。从安全角度来说，使用标准的 ASP.NET 基础架构把 BizTalk 业务流程公开为 Web 服务是有益的。我们可以把 WSE 安全性添加到处理管道中，方法与将其添加到任何其他 ASP.NET Web 服务中完全相同。 Microsoft 的 WSE 使用 ASP.NET 的 SOAP 扩展处理程序截取传入（和传出）的 SOAP 信封，以便能够处理 WS-Security 标头。如果您在开发计算机上安装了 WSE，则只需在 Visual Studio 中右键单击 Web 服务项目，就会看到一个新的菜单选项“WSE Settings 2.0...”。您可以通过该菜单选项对项目启用 Web 服务增强和 Web 服务增强 soap 扩展。前者在已安装的 WSE 程序集中添加一个引用；后者通过将列表 1 显示的配置部分添加到 web.config 文件中把 WSE 作为一个 SOAP 扩展添加到项目中（参见图 6）。 由于 BizTalk 是构建在标准的 ASP.NET 基础架构之上的，因此我们可以使用 web.config 设置的声明性方法把 WS-Security 纳入公开的 Web 服务。但这还不是全部 – 我们如何在业务流程中利用 WSE 身份验证过程下游的结果？ 一个显而易见的目标是将已经过验证的用户安全主体信息传递到下游。.NET Framework 使用实现 Iprincipal 接口的对象（称为安全主体）来保留已验证用户的身份和相关角色。WSE 用在传入的 SOAP 信封中处理的一些 WS-Security 令牌来设置安全主体对象。 为使安全主体信息可用于业务流程，需要将该主体添加到由服务器代理创建的消息的上下文中。将主体对象添加到消息上下文中是一个需要灵活处理的操作过程，因为 BizTalk Server 代理的接口不提供将任意元素添加到其所创建的消息的上下文中的工具。由于存在这一问题，我们必须欺瞒服务器代理以便将主体信息添加到消息中。我们通过将主体对象作为 SOAP 标头对象传递到服务器代理来完成上述目标。当服务器代理被 SOAP 标头集合调用时，它使用 XMLSerializer 序列化处理对象，然后将它们作为指定元素添加到消息上下文中。 在涉及到 Iprincipal 对象时，这种方法存在一个问题 – 标准实现（WindowsPrincipal 和 GenericPrincipal）将在使用 XMLSerializer 序列化处理它们的角色信息时丢失这些信息。为解决这个问题，我们编写一个转换功能，将主体对象转换为我们自定义的主体实现，这样就可以进行序列化处理而不会丢失任何信息。这里将不说明该转换过程的细节，但您可以在示例代码中查看详细信息。 要使用这种将主体添加到消息上下文中的技巧，我们创建自己的从 BizTalk 服务器代理中派生并覆盖其调用方法的服务器代理类。我们的服务器代理只是在保存安全主体的 SOAP 请求上下文中找到安全令牌，然后将其添加到输入 SOAP 标头集合中，然后将该集合传递给 BizTalk 服务器代理（参见列表 2）。 这个问题需要解决的唯一方面是如何创建一个从业务流程中访问该主体的便利方法。为实现这一目的，我们创建一个简单类（参见列表 3 中的 SecurityContext 类），它提供一个在消息上下文之外非序列化处理主体的静态方法。业务流程创建 IPrincipal 类型的一个变量，并通过表达式形式使用 SecurityContext 类来设置该变量。业务流程然后可以在其业务进程中使用该主体的标识或其 IsInRole 方法。示例代码通过其 SimpleOrchestration 示例说明这一方法。 作为设计业务流程的过程的一部分，BizTalk 允许设计人员通过将管道组件拖放到不同的消息处理阶段来创建管道。有了消息上下文中的主体，可以创建利用安全主体信息的自定义管道组件。例如，可以创建授权管道组件，以对某个授权数据库使用标识和角色信息来检查对业务流程的访问。另一个示例是创建参与方解析组件，以使用主体的标识来查找参与方目录中的配置方。通过针对已确定用户来解析参与方，业务流程可以使用对该参与方适合的渠道来传递响应数据。 图 7 说明了本文所讨论的所有组件如何与 BizTalk 结合以将业务流程公开为安全的 Web 服务。 使用安全的 Web 服务 本文已经说明虽然需要灵活地将验证结果传递到下游，但是将 WS-Security 添加到公开为 Web 服务的业务流程仍是一个简单事情。然而，这实际上只说了一半。如果我们要使用 BizTalk 作为反应灵敏的 SOA 的业务流程基础架构，我们必须能够使用安全的 Web 服务并公开安全的 Web 服务。遗憾的是，将这个功能集成到 BizTalk 中不是一件容易的事情。要理解其中的原因，您需要理解 BizTalk 如何使用不安全的 Web 服务。 要通过业务流程使用 Web 服务，您需要将 Web 引用添加到业务流程中，并将一个请求响应端口添加到使用该 Web 引用的业务流程中。在一般的 .NET Framework 应用程序中，添加 Web 引用会在名为 Reference.cs 的文件中为 Web 服务生成一个代理。该代理代码是从处理发送给 Web 服务的 SOAP 信封的创建过程的 System.Web.Services.Protocols.Soap HttpClientProtocol 类中派生。 如果 BizTalk 使用这一机制，则可以编辑生成的代理，使它们派生于我们自定义的类，从而可以实现 WS-Security 要求（当然利用 Microsoft 提供的 WSE 的工具）。遗憾的是，将 Web 引用添加到业务流程后，并不会生成上述代码，而是添加对 XLANG 规范的引用，然后生成代理代码，并在构建过程中将代理代码编译到业务流程程序集中。图 8 说明了现有的 BizTalk 组件是如何一起使用 Web 服务的。 作为 BizTalk 使用 Web 服务产生的结果，使用安全的 Web 服务的唯一方法是为现有的 SOAP 适配器编写安全的版本。开发这类适配器是一项超出本文范围的非同寻常工作，但是我正在考虑在不久的将来编写这样的适配器。 结论 本文已经论述了在构建灵活的面向服务的体系结构 (SOA) 中，BizTalk 是如何通过从子服务和旧版应用程序建立长期有效的过程来发挥至关重要的作用的。还讨论了 BizTalk 能够将其业务流程公开为安全的 Web 服务并使用安全的 Web 服务具有多么重要的意义。 我在前面讨论了 WS-Security 可以很容易在公开的 Web 服务顶层增加一层保护（并说明了如何向下传递安全信息），并遗憾地得出结论：通过业务流程安全使用 Web 服务没有捷径。通过添加安全的 SOAP 适配器来弥补这一缺陷外，BizTalk 将成为构建既灵活又安全的 SOA 的理想工具。 您有什么想法？ 请提供对本文的反馈意见。 关于作者 David Regan 是一名精通数据驱动和规则驱动的多层系统的自由系统编程员。(更多信息） |
