向业务合作伙伴开放公司的服务导向架构(SOA)，是否值得冒险一试？

　　Web服务通常被视为组织间共享数据的途径：企业可以有选择地向客户、合作伙伴以及供应商开放内部系统，从而将原来需要人工处理的交易自动化。虽然迄今为止多数企业依然尽力避免走这条路，而将Web服务置于防火墙的保护之下，但是随着服务导向架构(SOA)的发展和Web 2.0的出现，这一切都有可能改变。

　　向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服务。