一个设计正确的SOA安全性解决方案可以解决SOA中的绝大部分安全性问题。解决方案本身可以包含多个分别解决SOA安全性中的某个特定方面的子解决方案。根据具体需求和现有的安全性基础架构，不同的企业需要不同的解决方案。

　　SOAP消息监控

　　基于SOAP侦听的SOA消息监控是构建高效SOA安全性解决方案基础的一种手段。SOAP侦听

 
　　图1 一个用于监控SOAP消息的SOAP拦截器用作这个SOA中的安全性基础。SOAP拦截器分析它监控的SOAP消息的标题头中包含的用户身份，并将其与保存在现有安全性基础架构中的名称相比较。结果就是对SOAP消息发送方和接收方进行了身份验证和授权。

　　就是在web服务消费者和web服务之间来回传递的SOAP消息的路径中放入一个叫做“SOAP拦截器”的特殊软件块。因为其分类、监控、复制 和转发包含大量数据的SOAP消息的能力，SOAP拦截器可以在SOA安全性方面发挥重大作用。如图7所示，一个SOA安全性解决方案“监视”着到达 web服务的SOAP调用消息和对这些服务调用的响应。当它“看见”一条消息时，SOA安全性解决方案就会进行检查，以确保发出请求的实体是经过身份验证 和授权可以使用web服务的。SOA安全性解决方案通过检查SOAP消息标题头中包含的数据实现了这一点。

　　在大多数情况下，SOA安全性解决方案是对现有安全性解决方案的扩展，而现有安全性解决方案是在迁移到SOA之前为保护整个企业而部署的。因 此，SOA安全性解决方案很可能不得不与现有安全性基础架构进行连接和通信。如图7所示，SOA中的用户身份验证和授权发生在基于企业的授权用户数据库检 查用户证书的时候。侦听SOAP消息，并把消息标题头中列出的用户与保存在现有安全性基础架构中的用户进行比较，便可实现身份验证和授权。

　　SAML和联邦身份验证

　　当需要对企业外部的SOA用户进行身份验证和授权时，又会怎么样呢?SOA的开放性使得上述情况比以往任何时候都更可能出现。您可能会面临这样 一个难题:在一组在现有安全性基础架构中没有记录的用户中，搞清楚每个用户的身份。为了解决保护第三方过程中固有的安全性问题，SOA安全性解决方案可以 使用联邦身份验证。联邦身份验证是这样一个过程:通过这个过程，多方可以达成一致，使用一组给定的标准来对一组指定的用户进行身份验证。联邦身份验证方法 的使用者可以创建一个联邦身份管理系统(Federated Identity Management System)，这是一个已验证用户的库。SOA安全性解决方案可以通过检查联邦身份管理系统来对某个用户进行身份验证。换句话说，一些相互通信的系统的 “联邦”，可以一致同意某个用户是合法的。

　　在某些情况下，身份验证过程会导致在SOA安全性解决方案中创建安全断言标记语言(Security Assertion Markup Language，SAML)断言，用于以一种可为用户调用的web服务所接受的方式表达用户的真实性。SAML是一种基于XML的标准，它为以标准方式 描述安全性信息提供了一个框架。WS-Security是迄今为止得到认可的安全性标准集合的总称。许多SOA安全性解决方案都利用了这些新兴的安全性标 准。如图8所示，SOA安全性解决方案可以侦听SOAP消息，然后使其经过一个对用户进行身份验证的过程。接下来，SOA安全性解决方案把SOAP消息传 递给目的web服务，但是会附加上一个SAML断言。注意:SAML断言不依赖于联邦身份验证过程。

 
　　图2 要在SOA安全性中使用联邦身份验证，SOAP拦截器必须把传入的SOAP消息转发给安全性解决方案，该安全性解决方案再把SOAP消息标题头中包含的用 户身份与联邦身份验证数据库中列出的用户进行匹配。如果匹配成功，SOA安全性解决方案就会创建一个安全“断言”，内容是用户已经在安全断言标记语言文档 中通过了身份验证，该文档是在SOAP消息到达它要调用的web服务时附加给该SOAP消息的。

　　应用程序代理

　　一种非常有效的保护核心系统的方法是避免让任何人访问驻留平台的服务。可以通过为SOA中的web服务部署一个代理做到这一点。如图9所示，一 个受保护的代理可以代表实际的web服务接收所有web服务请求，并对其做出响应，从而保护web服务免遭恶意的侵害。代理方法的另一个好处在于，它能够 减轻企业安全性基础架构的负担。代理可以降低网络流量，具体方法是集中管理和缓存对web服务请求的身份验证和授权，而不是每次用户想调用web服务时， 就在网络上使用大量消息对该用户进行身份验证和授权。代理还在消息中插入了身份验证和授权SAML断言，从而消除了实际web服务直接查询安全性系统的需 要。

　　契约管理

　　在下一章中，我们将花大量时间来讲述这个主题，但是作为主要的SOA管理问题之一，契约管理同样在SOA安全性中起着举足轻重的作用。契约就是 用于管理web服务使用情况的一组规则。例如，某个契约可能会规定，某个特定用户有权每天调用某个特定的web服务十次。而且在调用过程中，服务水平必须 满足特定的参数，比如一秒钟的响应时间。

　　在安全性方面，契约有助于确定SOA是否运行正常，或者由于违反安全性规则而误用。如图10所示，SOA拦截器把web服务请求和响应数据发送 给SOA安全性解决方案，然后该SOA安全性解决方案再确定是否满足契约。如果某个安全性问题(比如DoS攻击)使web服务的速度降低到契约规定的服务 水平以下，SOA安全性解决方案就会警告管理方有问题存在。当然，一次足够严重的攻击可以导致整个网络崩溃，但是安全性解决方案至少可以发出有问题存在的 通知。

 
　　图3 通过处理SOAP消息流量，降低企业安全性基础架构的负担，并保护web服务免于误用，web服务代理有助于保护SOA。

 
　　图4 SOA安全性解决方案监控服务水平，并在安全性问题导致web服务降低到契约规定的服务水平以下时发出警告。

 
　　证书、密钥和加密

　　这些年来，IT领域先后出现了很多消息级的安全性技术，包括密码术。现在，也可以对SOA应用这些技术。这些过程，包括数字签名、证书、密钥和 加密，都可用来保护SOA。在这里我声明一点:对于这4种安全性技术中的每一种，都可以写出一本甚至是好几本著作。请把本节看作是对与SOA相关的基于加 密的安全性的一个概述。

　　如果希望让SOA拥有健壮的安全性，保证web服务的用户都可以得到适当的身份验证，而未经身份验证的人无法读取在web服务及调用它们的应用 程序之间往返的信息，那么无疑需要对SOA安全性解决方案应用功能强大的公钥/私钥加密工具。密钥是一个具有某种特殊的数学特性的大数(数百个数位)。尽 管形式和大小各不相同，但密钥都有一个基本属性，即，可以与另一个密钥进行惟一关联。也就是说，当一个密钥遇到其惟一的匹配密钥时，双方都会说，“哦，就 是你了，我惟一的匹配…不会再有其他的什么人了。”

　　惟一的密钥对具有如下两个基本功能:

　　•因为它们是惟一的，所以它们是非常强大的身份验证工具。
　　•由于它们的数学特性，它们可用于创建经过不可测知的过程进行加密的惟一消息，这些消息只能被拥有惟一的匹配密钥对的用户所读取。

　　下面讲述当两个用户想交换加密信息时的工作原理:用户A创建一个惟一的密钥对。然后，他在自己的系统中隐藏其中的一个密钥(“私钥”)，却把另 一个密钥(“公钥”)发送到用户B可访问的网络上某处。然后，用户B使用公钥来加密他想要发送给用户A的信息。实际过程涉及到大量让我想一想就头痛的数学 知识，但是基本上，公钥和消息数据是通过一个加密算法来运作的，该加密算法生成一个没有私钥不可能打开的加密文件。接下来，用户B把经过加密的消息发送给 用户A，而用户A则使用最初隐藏的私钥来对加密数据进行解密。结果，用户A是世界上惟一一个能够解密这些加密数据的人，因为(只有)他拥有与用户B的公钥 匹配的惟一私钥。

　　现在，如果您像我一样爱刨根问底，您可能会想，但是用户A如何知道用户B真的是用户B呢?如果某位黑客侵入到用户B的系统中，并找到了他使用的 公钥，那怎么办呢?为了回答这个有效性问题，人们使用了大量实体来确保特定用户的真实性，并授予他们证明其真实性的数字证书。这些实体叫做 certificate authority (认证机构，CA)。CA的一个著名例子是VeriSign，它提供用于电子商务事务的证书。

　　使用密钥、加密和证书来实现保密性和身份验证的SOA安全性解决方案如图11所示。在我们的制造商例子中，供应商系统想发送一条SOAP消息给 制造商的web服务。为了做到这一点，制造商必须首先发送一个公钥给CA。然后，供应商系统从CA请求一个证书。供应商收到的证书包含与制造商系统中存在 的私钥相匹配的公钥。然后，供应商使用证书的公钥加密其消息，然后再把消息发送给制造商。然而，和前面的例子一样，SOA安全性解决方案侦听消息，并使用 CA检查证书的有效性。这可以验证供应商的身份。只有在通过身份验证之后，加密后的SOAP消息才能被发送给制造商。SOAP消息到达之后，制造商就使用 它的私钥对消息进行解密和处理。

　　如果您觉得这听起来更多地像是在发送消息，那么您想得没错。就像在IT的其他领域中一样，SOA中的安全性会带来大量“开销”。在到达目的地之 前，每条消息都必须经过好几个地方。证书文件可能会很大，从而给网络造成很大的负担，而且整个过程往往会降低性能。但是遗憾的是，它仍然是必不可少的。

　　XML加密

　　图 5 在安全性SOA中使用公钥/私钥加密和证书的步进式过程

　　1.制造商将公钥发送给认证机构，并将私钥隐藏在自己的域中
　　2.供应商从认证机构请求包含制造商公钥的证书
　　3.供应商向制造商发送使用公钥进行加密并包含证书的消息
　　4.SOA安全性解决方案向认证机构发送证书，以便对供应商进行身份验证
　　5.SOA安全性解决方案向制造商发送使用私钥进行加密的SOAP消息

　　为了保留SOA的开放性，同时制订严格的消息级的安全性标准，您很可能想在加密时使用XML。当SOA安全性解决方案使用密钥对消息进行加密 时，它会把消息转换为一段经过加密的XML。消息是XML格式的，但是内容并不可见，因为使用加密算法将其隐藏起来了。这样做的好处在于，接收消息的系统 可以把它当作XML来接收、解密和处理，而不依赖于定制或专有的消息传递标准。这样我们就获得了安全性，同时系统仍然基于开放标准。

　　数字签名

　　数字签名是另一种消息级的安全性形式，它是证书、密钥和加密等安全性方法的变体。数字签名就是附加给SOAP消息的证明真实性的数学语句。数字 签名是一个基于密钥的数(同样是一个非常大的数)，它对您的身份和消息内容进行惟一的处理，具体方法是对两组数据(密钥和消息)运行一个特殊的算法。举一 个简单的例子，如果您的消息是“hello”而密钥是12345，算法将处理这两种输入——单词“hello”的数值和密钥数12345——并生成第三个 数，这第三个数就是数字签名。当接收系统获得消息和附加的数字签名时，它可以使用密钥来验证以下内容:

　　•您是消息的真正创建者(身份验证)，
　　•SOAP消息在传输过程中没有改变。

　　如果消息被改变了，那么惟一的数字签名将不再与密钥和用于创建密钥的原始消息相匹配。数字签名和先前描述的完整加密过程之间的区别在于，如果使 用数字签名，不必对整条消息进行加密。因此，系统的性能得到了提升。只要您不介意别人可以看到您的纯文本格式的消息，那么数字签名就可以为SOA提供高度 的数据安全性和完整性。

　　签名可以是一个不可否认性(nonrepudiation)组成部分，该特性是一个需要在SOA环境中解决的安全性重要方面。不可否认性是指一 个组织的一种能力:验证发生了特定的处理，并从而不给发送方提供否定进行了处理的机会。例如，如果您针对某种商品下了一份电子订单，而该订单并没有以某种 方式(比如使用数字签名)进行验证，那么对方就有可能否认收到该订单。如果批发商的系统提供不可否认性，那么批发商就可以肯定该订单已经送达。

　　重放攻击保护和审计

　　最后，SOA安全性解决方案应该提供一种用于跟踪SOAP请求的工具，从而降低DoS攻击带来损害的可能性。通常，跟踪特性将监控SOAP消息 的发送方及其创建时间。在某些情况下，SOA安全性解决方案将使用一个惟一的识别码给SOAP消息打上印记。如果解决方案被设置为阻塞复制消息，那么同一 条消息是不可能被发送两次的。消除这种可能性有助于降低黑客使用复制请求淹没SOA的可能性，这是DoS攻击中常用的一种手法。

　　审计是SOAP消息跟踪功能的进一步发展。如果SOA安全性解决方案被配置为跟踪消息，那么它应该能够生成特定时期中SOA消息流量的使用日志 和审计报告。审计有很多用途，但是在安全性领域中，它用于记录所发生的事情，以便研究安全性问题并诊断潜在的安全漏洞。这类日志已经成为实现管理目标(比 如对Sarbanes-Oxley法案的服从)所必不可少的。

　　明智的管理人员所给出的忠告:不要让安全性吓倒了您

　　SOA安全性是一个很大的主题。我可以就这个主题写一本书。(事实上，这是一个不错的主意…)在本章中，我的目的是提供一个概述，好让您可以评 估自己对这个主题所掌握的信息。如果您是一位企业主管，我的建议是，要避免被安全性问题吓倒。人们很容易被安全性吓倒，安全人员也不例外，这阻止了他们做 些实际工作以消除对于安全性问题的恐惧。实际上，我本来可以提出一个您正在考虑的IT解决方案，并让您了解到围绕该解决方案的大量安全性噩梦，这些噩梦足 以使您远离该解决方案。

　　相反，我建议您寻求安全性方面的高质量建议，并探讨企业中已经实施了哪些。如果您这样做，那么您的企业就很可能会拥有一个(或一些)相当健壮的 安全性系统。实施SOA的难点在于如何把现有的安全措施扩展成为由SOA构成的web服务。许多SOA安全性解决方案的设计目的就是为了与现有的安全功能 有效互连。如果实现的话，安全性风险可能稍微易于管理一些，而您也可以继续实施您的计划了。

　　结束语

　　安全性是SOA中的一个焦点问题，因为SOA强调机器与机器的交互，而大多数IT安全性都是基于人与机器的交互。身份验证和授权在这个环境中变 得更加富于挑战性。在未受保护的SOA中，想要阻止web服务的未授权使用实际上是不可能的;未授权用户可以非常轻松地访问web服务。Web服务不具备 跟踪谁在使用它们或者谁被允许使用它们的固有功能。无法阻止不必要的监听和消息侦听。未受保护的SOA让黑客有机会监听SOAP消息并看到私密信息。此 外，在未受保护的SOA中，侦听SOAP消息并(出于危害和欺骗的目的)重新发送消息或转换消息内容要相对容易一些。

　　由于SOA架构的开放性本质，您无法保护SOA中未知的第三方。第二级和第三级用户(例如您的合作伙伴的合作伙伴)是可以访问未受保护的SOA 的。因此，未受保护的SOA很容易超负荷运转。如果没有访问控制，未受保护的SOA很容易被来自黑客的大量SOAP消息所“淹没”。结果可能导致DoS攻 击损害系统的正常功能。最后，您还没有处理记录。未受保护的SOA无法跟踪其用户或消息。因此，没有可用于研究安全性问题或诊断安全性漏洞的可审计使用记 录。

　　存在一些可以解决所有这些问题的预打包和定制的SOA安全性解决方案。在分析SOA安全性需求时，可以考虑实现一个支持SOAP消息监控、联邦 身份验证、应用程序代理、契约管理、证书、密钥和加密以及审计记录的SOA安全性解决方案。这个清单似乎很长，但是事实上，如果缺少其中任何一项，SOA 的所有优点都可能遭到破坏。

　　SOAP消息监控利用了一个SOAP拦截器模型，以便在将SOAP消息从调用系统发送给web服务时对其进行侦听和监控。SOAP消息监控是 SOA安全性的基础，因为它让安全性解决方案能够停止和分析每条消息，以进行用户身份验证和授权。为了保护第三方，安全性解决方案可以利用联邦身份验证。 应该通过一个联邦身份验证过程提供对系统中的用户进行身份验证的能力。最终将获得一个为web服务的用户提供可信身份验证的SAML断言。

　　Web服务应用程序代理在实际的web服务中接收和处理SOAP请求，从而对安全性有所帮助。它可以使所有的用户都远离实际的服务。代理不仅可以减轻网络的负载，还可以为SOA提供一个额外的安全性层。

　　契约管理是另一项对安全性有所帮助的SOA管理特性。契约确立了谁有权使用web服务以及何时可以使用它。契约通过消除非契约方的使用，提高了SOA的安全性。

　　对于一个真正安全的SOA来说，证书、密钥和加密同样是必不可少的。最健壮的SOA安全性都源于实现了使用来自认证机构的私钥/公钥进行身份验 证的加密消息传递。XML加密允许web服务用户发送保留XML格式的加密SOAP消息。因此，系统实现了安全性，但却仍然基于标准。数字签名是加密模型 的一种变体，它使得web服务的用户可以创建一个惟一确认的数字“签名”，其用途有二:验证用户身份和确保消息数据的完整性。

　　最后，为了跟踪SOA的使用，有必要采用可以保存所有SOAP消息请求和响应的动态审计日志的SOA安全性解决方案。审计日志对于在SOA中研究安全性问题和诊断安全性漏洞，以及实现管理规章服从性，都是必需的。