如今许多公司把各自面向服务的架构(Service-Oriented Arthitecture，SOA)向业务合作伙伴开放，那么你是否准备好了应对由此带来的种种风险呢?

　　Web服务一直被认为是组织之间共享数据的一条途径：企业可以有选择地向客户、合作伙伴和供应商开放内部系统，从而让曾经需要人来干预的交易实现自动化。虽然到目前为止，大多数公司避免走这条路，把Web服务放在防火墙后面保护起来，但是服务服务的架构(SOA)的发展和Web 2.0的兴起势必会改变这种情况。

　　向万维网开放内部服务带来的回报是否大于风险?糟糕的是，SOA安全标准的不成熟加剧了互操作性方面的难题。如果想严加保护牵涉多家企业的庞大Web服务网络，每家企业必须就采用的技术、甚至安全策略达成共识：如果合作伙伴的员工使用弱密码来访问系统，那么要求贵企业的员工使用生物特征识别技术和物理令牌是毫无用处的。

　　在购买SOA安全系统的部件之前，要做必要的准备工作，因为市场在不断变化。总的说来，市场上出现的动向对IT人员来说是好消息，因为这意味着更多的选择;要打交道的厂商也可能更少了。但这同时使得采购决策大大复杂化。

　　举例说，暴露在互联网面前的Web服务需要XML防火墙(又叫SOA安全网关)。然而，由于SOA方面不断合并，这一类产品正开始销声匿迹。

　　与此同时，由于XML防火墙功能集成到从管理平台到核心交换机在内的各种产品，选用哪种产品、甚至像使用硬件还是使用软件这些基本决策，将不但取决于任何现有的SOA基础架构，还取决于每家企业的Web服务的规模及预计增长。而虚拟化技术增添了另一个意想不到的变数。

　　加密和验证方面的决策更困难，因为它们并不依赖某一家公司。Web服务外联网中的每家公司都要使用同样的技术;眼下有好几项彼此竞争的标准。

　　最大的冲突在于身份管理方面，这项复杂工作旨在确保登录到某一家公司系统的用户或者流程获得授权，可以使用合作伙伴的这些系统。这方面已出现了两项不相兼容的标准，它们提供的功能大致一样。第一种是安全声明标记语言(SAML)，该标准得到了除微软之外几乎每家公司的支持;微软更喜欢比较新的Web服务联合身份验证(WS-Federation)，该标准与其他Web服务标准的关系更为紧密。虽然两者都使用XML，但彼此互不兼容，这意味着使用公共Web服务的企业必须要么同时支持这两项标准，要么确保使用安全Web服务的所有业务合作伙伴都选择同一项标准。

　　似乎具备未卜先知的本领才能在两者之间做出合理选择。

　　混合消息

　　所有Web服务安全技术都基于XML加密(XML Encryption)和XML签名(XML Signature)，万维网联盟(W3C)的这两项标准用于把加密数据和数字签名嵌入到XML文档或者消息内。因为XML加密标准不必对整条消息进行加密，所以这给了IT人员自由选择的余地：可以对社会保障号或者信用卡号等私人数据进行加密;而不太敏感的消息和SOA元数据可以用明文格式传送。也可以使用不同的密钥对某个文档的不同部分进行加密，这样只有预期的接收者才能读取。

　　不利的方面在于：XML消息里面散布的加密数据会导致互操作性问题，因为参与者必须首先就加密数据放在消息中的哪个位置、哪些元素需要加密以及如何交换密钥等问题达成一致。为了帮助解决这个问题，结构化消息标准促进组织(OASIS)制订了Web服务安全(WS-Security)标准，用于在Web服务中运用XML安全和XML加密。

　　Web服务安全标准是WS-*系列标准中最成熟的，得到了几乎所有Web服务和SOA厂商的支持。其主要缺点是，与所有WS-*标准一样，Web服务安全标准也需要简单对象访问协议(SOAP)――业务中用到运行代表性状态传输(REST)的Web服务的公司都不适用于该标准;REST这种方法是用来描述不用SOAP的XML Web服务。

　　使用REST而不是SOAP的主要理由在于简洁性，所以大多数REST用户坚持使用安全套接层(SSL)协议。由于REST需要HTTP，而且往往用于点对点链路，所以SSL隧道常常足够了。如果企业希望在REST中运用消息层安全，就要创建自己的协议和数据格式。

　　把每一个业务合作伙伴召集起来，并为REST设计一种定制、安全的XML格式，这很难吸引大多数企业，所以Web服务安全标准的存在是支持SOAP的一大理由。不过，包括亚马逊和Google在内的各大Web服务提供商各自成功开发了保护REST安全的方法，使用了实际上是共享钥匙(shared secrets)的安全令牌。尽管这些方法是专有的，但备受用户的欢迎：亚马逊也提供符合Web服务安全标准的SOAP接口，但发现其客户更喜欢REST，两者用户比例为1:5。大多数亚马逊用户只是访问亚马逊的服务，而不是构建完整的SOA，所以不需要SOAP的复杂性。

　　联合身份

　　虽然Web服务安全标准有助于对SOAP消息进行加密和签名，但它不涉及有关验证、授权和计费(AAA)或者安全策略的任何内容。这些方面通过其他标准来处理;在安全领域里面，这些标准都基于Web服务安全标准。