向Web开放内部服务是否过于冒险?虽然SOA安全标准不成熟加剧了互操作性的负面影响，但这并不能成为决策依据。欲对有多个企业参与的大型Web服务网络进行配置，以确保其安全，所有参与者必须就所采用的技术和安全策略达成共识。否则，就会出现不合理的局面：一方面，你要求自身的雇员使用生物测定技术或者身份标志来验明正身，另一方面，合作伙伴的员工只需要通过弱口令认证就可以访问你公司的系统，这样的安全防护，毫无意义。
在采购任何SOA安全部件之前，需要先对SOA安全进行深入研究，因为市场始终在变。无论如何，眼下如火如荼的SOA运动对IT部门而言，终究是好事，因为这样一来他们手中会有更多的选择，需要打交道的厂商也少了。与此同时，采购决策的过程也变得更为简单。
例如, 将Web服务暴露于互联网，需要基于可扩展标记语言(XML)的防火墙，也称为SOA安全网关。然而，随着SOA技术的不断整合，这一产品类型已开始销声匿迹。
现在，从管理平台到核心交换机在内的所有产品都添加了XML防火墙功能。选用何种产品、到底是用硬件还是用软件，取决于每个企业Web服务的规模、预期增长、以及现有的SOA基础设施等因素。此外，虚拟化技术还进一步加大了系统选择的难度。
加密和认证的决策更为艰难。因为那并非只取决于某一个组织，而是接触Web服务的所有组织都必须使用同样的技术。然而，现在这一领域存在着好几个相互竞争的标准，加深了问题的复杂性。
这些标准之间最大的冲突在于身份管理。这个复杂过程的目的是确保登录用户已被授权使用该公司合作伙伴的系统。目前有两个互不兼容但功能相近的标准。一个是安全性断言标记语言 (SAML)，这一标准已经得到几乎所有公司的支持，唯一的例外是微软公司(Microsoft，下称微软);微软更喜欢较新的WS-Federation标准。后者与其他Web服务标准的关系也更为密切。虽然二者都用XML，但是彼此并不兼容，因此那些推行公共Web服务的企业要么同时支持这两种标准，要么需要确认其所有采用安全Web服务的商业合作伙伴选择的是同一个标准。
看来，得有未卜先知的本事，才能在两者间做出合理的决策。
各种相关信息
所有Web服务安全技术均建立在XML加密(XML Encryption)和XML签名(XML Signature)的基础之上，W3C标准用于在XML文档和信息内嵌的加密数据和数字签名。由于XML加密技术无需对全部信息进行加密，因此IT部门可自由选择：可对信用卡号码等个人数据进行加密，而敏感度不高的信息和SOA元数据无需加密即可传送。也可给文档的不同部分分配不同的密钥，以使其只能被指定的接收者读取。
但这也有不利的一面：由于参与者必须首先就加密数据的位置、加密元素和如何交换密钥等问题达成一致，因此散布于XML信息中的加密数据会导致互操作问题。为解决上述问题，结构信息标准化促进组织 (OASIS)建立了WS-Security标准，以在Web服务中应用XML安全(XML Security)和XML加密。
WS-Security标准是WS-*系列标准中最成熟的一个，几乎所有Web服务和SOA厂商都支持这一标准。其主要缺点是：与所有的WS-*系列标准一样，也采用简单对象访问协议(SOAP)，因此凡业务依赖于REST Web服务的公司，都不适用此标准。 REST(Representational State Transfer)意为具象状态传输，采用这种模式，可对不用SOAP的XML Web服务进行描述。
选择REST而非SOAP的主要原因在于它的简捷，多数REST用户仍然使用SSL协议。这是由于REST采用HTTP协议，而且往往被用于点对点连接，故而SSL隧道通常已能满足其需求。在应用了REST以后，企业如果希望对消息层进行加密，就需要建立其自己的协议和数据格式。
对于多数企业而言，将所有商业合作伙伴组织起来，并为REST设计定制的、安全的XML格式，实属不易，WS-Security标准因此而成为采用SOAP的最强有力依据。尽管如此，亚马逊公司(Amazon.com)和谷歌公司(Google)等大型Web服务提供商纷纷各显神通，使用安全身份标识(Security Token)，成功地应用了REST模式。这样做虽然有沦为专有技术的顾虑，但仍然受到了用户的欢迎：亚马逊也提供遵从WS-Security的SOAP接口，但发现客户更青睐REST，使用二者的用户比例为5:1，因为多数亚马逊用户仅仅是访问亚马逊服务，而不是用之建立完整的SOA，所以也就用不着SOAP的复杂功能。
统一身份
尽管WS-Security标准有助于SOAP信息的加密和签名，但该标准并未涉及任何有关认证、授权和计费(AAA)或者安全策略的内容。这些问题由安全领域的其他标准解决，并且所有这些标准都以WS-Security为基础。
虽然目前这些标准由于太新而无法对用户产生足够的影响，但是其中多数最终将得到企业服务总线(ESB)和Web服务管理领域所有厂商的支持。
唯一的例外是统一身份的问题，也恰是在这一领域，安全标准新秀WS-Federation和WS-Trust对OASIS组织发布的另一成熟标准SAML 2.0发起了挑战。采用统一身份的目的在于：将认证与被访问的资源分隔开来，以实现单点登录。用户登录到某身份提供者的系统，后者为之提供凭证，该用户即可使用此凭证访问多个不同资源。凭证与数字证书近似，在SAML中称之为“断言”，在WS-Trust中唤作“标识”;一般用凭证来担保用户身份，并在认证时添加一些信息，例如用户在何时以什么方式登录。SAML作用于整个单点登录过程，而对于WS-*来说，这一过程由两个标准共同完成：WS-Trust负责处理内部认证和标识的发放，WS-Federation负责管理用这些标识访问其他资源的操作。
实际上，二者的主要差别在于：SAML直接使用XML加密和XML签名，这意味着它与REST兼容;而WS-Federation则采用SOAP。SAML拥有庞大的客户群，但是这实际上意义不大，因为微软一直在全力推进WS-Federation，并表示不会支持SAML。
与其他的标准之争不同，在这一案例中，并非是微软与其他所有公司的简单对抗。
一方面，微软与国际商业机器公司(IBM)共同开发了WS-Federation标准，而后者同时也是SAML的拥趸;另一方面，SAML阵营中其他所有厂商均已承诺，如果WS-Federation存在市场需求，他们都会支持这一标准。从长远来看，二者将会并存：微软和SOAP环境会选择WS-Federation，而REST Web服务则是SAML的天下。
防火墙置于何处
在互联网的发展过程中，防火墙是最早推动Web服务普及的因素。虽然不同的组织采取不同的安全策略，但是几乎所有组织都需要开放80端口(编者注：Web服务端口)，所以厂商和标准组织纷纷倾向于采用运行在HTTP之上、基于文本的协议。
当然，攻击者和恶意软件也持同样的态度。
因此，在互联网上发布Web服务的公司传统上往往使用应用安全网关，这些设备可以读取并理解应用层文档，从而能过滤潜在的攻击。虽然好产品的功能不仅限于XML领域，通常仍称这类设备为“XML防火墙”。尽管基于浏览器的富互联网应用(RIA)开发人员往往认为XML过于庞杂，而喜欢用JavaScript 对象表示法(JSON)或纯文本格式，但REST Web服务仍可在HTTP或URL中对某些信息进行编码。
安全网关不仅仅是防火墙，它具备SOA管理套件的所有功能，可以处理认证、授权和计费。当Web服务作为企业SOA的一个接口存在时，安全网关通常需要在Java信息服务(JMS)和HTTP之间进行转换，原因在于多数SOA在其内部并不使用真正的Web服务。
除非连接到外部世界，否则能穿越防火墙反而成为一大不利因素。
此外，网关需要先对文档进行解码，然后才能对之进行有效审查，因此不管采用SSL、WS-Security或SAML格式，多数网关同时也负责加密和认证。由于识别攻击要用到深度包检测技术并能理解XML，因此XML转换和路由也要用到安全网关，而且由于采用了专业化的SSL或XML加速硬件，安全网关在此方面往往优于管理软件。
现在，绝大多数安全网关仍是独立机箱，安装方式与传统防火墙相近，由专业厂商销售。
在网络中，无论安全网关以硬件还是软件的形式部署，它的作用都不仅限于阻止XML攻击。由于许多企业级SOA使用Java信息服务(JMS)，因此他们必须将之转换为HTTP格式，以通过Web发送。
安全网关厂商的先行者中，有4家已成为他人的囊中之物：Sarvega公司为英特尔公司(Intel)所购;NetScaler公司被思杰公司(Citrix)收至攠下;IBM和思科公司(Cisco Systems)分别买下了DataPower公司和Reactivity公司。除了英特尔之外，其他几家现在仍然销售网关产品。英特尔则利用Sarvega技术帮助其他厂商，围绕标准CPU而不是定制ASIC芯片开发XML软件或设备。
思杰的NetScaler设备集成了XML防火墙与应用前端(AFE)。Cisco也计划将Reactivity集成到其应用控制引擎(ACE)产品线中，以达到同样的集成目标。由于AFE位于网络边缘，而且用于加速SSL，因此，无论对于客户还是期望挺进新市场的AFE厂商而言，AFE与XML防火墙的集成都可谓意义重大。F5网络公司(F5 Networks)也宣布将会销售自主研发的XML防火墙，而且其竞争对手很可能会步其后尘。
利基网络公司(Layer 7 Networks)、 Vordel公司和Xtradyne公司等其他独立安全网关厂商则与之背道而驰，以软件和虚拟化为发展方向。其中，Vordel公司和Xtradyne公司始终将其网关产品作为软件来销售，运行于专用刀片服务器环境。而且这几家公司都极推崇虚拟设备，利基网络公司和Vordel公司已开始销售运行于VMware系统环境下的软件。
虚拟化的机会
尽管如此，虚拟设备还无法与专用服务器相提并论，这也是为什么Vordel公司现在更关注对其虚拟软件进行测试和集成，而非产品化。利基网络公司成立伊始，就将自身定位于采用专用XML和SSL硅技术的定制设备厂商。在他们眼中，对于那些尚无法确认是否该采用专业硬件设备的小公司而言，虚拟化技术不失为一个切入点。尽管“纯软件”迄今听起来仍像是出于预算考虑的折衷之策，但很可能虚拟设备很快会应用在各种规模的企业之中。
虚拟机的性能在迅速提升，而且虚拟化带来的灵活性在SOA应用中有着特别的意义。由于要大量部署并再利用新服务，SOA架构需要进行调整，而借助虚拟化技术，可以迅速地将硬件设备在不同任务之间进行再分配。但是，只有其他服务器也实现虚拟化，才能共享硬件资源，而这会导致安全性问题。尽管很少见到有关VMware安全漏洞的报告，但管理多个虚拟机的工作异常复杂，因此很可能会有数据流偶尔绕过防火墙。
SAML和WS-Federation均将服务和认证分离。用户首先需通过某身份提供者的认证(1)，该提供者会为之提供XML凭证(2)。用户可使用此凭证再次访问一个或多个服务，而不必再次登录(3)。用户当前访问的服务，可以选择对身份提供者进行检查(4)，以验证用户的身份(5)。在连接两家企业的Web服务中，身份提供者通常与用户位于同一家企业，而服务既可以是内部的也可以是外部的。
鉴于安全网关与Web服务管理软件之间存在太多的重复功能，二者目前已开始融合。DataPower公司和Reactivity公司在被收购之前均已进入管理软件市场，而且至少还有另外一家防火墙厂商也计划效仿。迄今为止，管理软件厂商尚未在其软件中添加完整的XML防火墙功能以进行反击，主要原因在于，其软件均定位在运行于整个SOA平台之上，而非边缘部分。
由于SSL的盛行，安全网关普遍具备SSL加速功能：甚至虚拟设备厂商也支持搭载SSL加速卡的硬件。相形之下，XML加速要罕见得多，只有利基网络公司、思科和IBM的设备采用专用XML芯片;IBM是自行研发，思科和利基网络公司用的是Tarari公司的技术。形成这种局面的部分原因在于，英特尔利用Sarvega技术帮助其他公司开发XML产品，但主要还是由于应用层加速的市场需求不足;而且，利基网络公司相信，硬件市场会逐渐过度到软件。
对于那些负责传输SOAP或SAML信息等较长XML文档的Web服务来说，XML加速的价值难以言喻;而在定位于支持基于浏览器应用的Web服务中，这一技术用得不多，原因在于这类服务在每个会话中传输的数据都很少(可能只有一个XML元素或者JSON对象)，而且置于TCP/IP和HTTP包头中。由于JavaScript和Flash客户端无需为用户的每次操作刷新整个页面，因此多数Web 2.0应用中涉及的应用层数据传输，要少于用静态可扩展超文本置标语言(XHTML)开发的同类应用。
尽管如此，Web服务器在RIA中还占有一席之地。尽管RIA可能会减少XML传输，但他们也会极大地增加服务器需要处理的HTTP连接的数量。多数RIA并不等待用户点击链接，而是实时运行，每隔几秒钟就需要建立新连接。而采用SSL加速和其他AFE技术，包括负载平衡和HTTP压缩在内，往往可以减轻因此而超载的服务器的负担。
安全标准，过犹不及?
在服务导向架构(SOA)领域，标准无处不在，Web服务(WS-*)更是会继续膨胀，以影响到所有可能的简单对象访问协议(SOAP)应用案例。尽管如此，专门针对安全问题而制定的标准却屈指可数，而那些无所不包的标准则环环相扣，彼此依赖。现在，SOA领域的“物质基础”已然尘埃落定，而“上层建筑”仍在建立之中。
• WS-Security 1.1。 描述如何将XML加密(XML Encryption)和XML签名(XML Signature)应用于SOAP文档或信息。此标准得到了所有厂商的支持，同时也被用于其他所有与安全相关的WS-*标准中。其最新版本发布于2006年2月，很可能也是最后一个版本，因为未来的改进将被纳入其他标准。
• WS-SecurityPolicy 1.2。 对哪些人被允许访问某个服务以及访问方式做出规定，并对认证方式的类型和/或所需要的加密等级做出限制。他是Web服务策略(WS-Policy)的子集，以更为通用的方式对服务的能力和限制进行描述。此标准由国际商业机器公司(IBM)和微软公司(Microsoft)共同开发，并于2007年7月正式确立，最终将会得到所有厂商的支持。
• WS-SecureConversation 1.3。 是按照WS-Security标准，实施WS-SecurityPolicy中所描述的策略的方法。此标准于2007年3月通过审批;与此同时，IBM和太阳计算机系统公司(Sun)演示了此标准的实施过程。尽管现在鲜有客户使用此标准，Actional公司、毕益辉公司(BEA Systems)、思科公司(Cisco System)、CA公司、利基网络公司(Layer 7 Networks)、甲骨文公司(Oracle)、Reactivity公司、RSA安全公司(RSA Security)以及VeriSign公司等其他厂商也都表示支持此标准。
• WS-Trust 1.3。 应用WS-Security标准传输密码、数字证书以及安全性断言标记语言(SAML)断言等安全标识。非SOAP Web服务与XML密钥管理规范 (XKMS)和SAML有部分相同之处。
• WS-Federation 1.1。 根据WS-SecurityPolicy中描述的服务规则，应用WS-Trust中提到的被传输的安全标识，通过Web服务的认证。由于与SAML的许多功能相同，目前尚未得到广泛应用。相较SAML，他的主要优势在于，Windows支持这一标准，而且与WS-*之间结合紧密。
