面向服务架构SOA：勇敢者的游戏[1]

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

　　Web服务通常被视为组织间共享数据的途径：企业可以有选择地向客户、合作伙伴以及供应商开放内部系统，从而将原来需要人工处理的交易自动化。虽然迄今为止多数企业依然尽力避免走这条路，而将Web服务置于防火墙的保护之下，但是随着服务导向架构(SOA)的发展和Web2.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加密(XMLEncryption)和XML签名(XMLSignature)的基础之上，W3C标准用于在XML文档和信息内嵌的加密数据和数字签名。由于XML加密技术无需对全部信息进行加密，因此IT部门可自由选择：可对信用卡号码等个人数据进行加密，而敏感度不高的信息和SOA元数据无需加密即可传送。也可给文档的不同部分分配不同的密钥，以使其只能被指定的接收者读取。

　　但这也有不利的一面：由于参与者必须首先就加密数据的位置、加密元素和如何交换密钥等问题达成一致，因此散布于XML信息中的加密数据会导致互操作问题。为解决上述问题，结构信息标准化促进组织(OASIS)建立了WS-Security标准，以在Web服务中应用XML安全(XMLSecurity)和XML加密。

　　WS-Security标准是WS-*系列标准中最成熟的一个，几乎所有Web服务和SOA厂商都支持这一标准。其主要缺点是：与所有的WS-*系列标准一样，也采用简单对象访问协议(SOAP)，因此凡业务依赖于RESTWeb服务的公司，都不适用此标准。REST(RepresentationalStateTransfer)意为具象状态传输，采用这种模式，可对不用SOAP的XMLWeb服务进行描述。

　　选择REST而非SOAP的主要原因在于它的简捷，多数REST用户仍然使用SSL协议。这是由于REST采用HTTP协议，而且往往被用于点对点连接，故而SSL隧道通常已能满足其需求。在应用了REST以后，企业如果希望对消息层进行加密，就需要建立其自己的协议和数据格式。

　　对于多数企业而言，将所有商业合作伙伴组织起来，并为REST设计定制的、安全的XML格式，实属不易，WS-Security标准因此而成为采用SOAP的最强有力依据。尽管如此，亚马逊公司(Amazon.com)和谷歌公司(Google)等大型Web服务提供商纷纷各显神通，使用安全身份标识(SecurityToken)，成功地应用了REST模式。这样做虽然有沦为专有技术的顾虑，但仍然受到了用户的欢迎：亚马逊也提供遵从WS-Security的SOAP接口，但发现客户更青睐REST，使用二者的用户比例为5:1，因为多数亚马逊用户仅仅是访问亚马逊服务，而不是用之建立完整的SOA，所以也就用不着SOAP的复杂功能。

[1][2][3][4]