对于多数企业而言，将所有商业合作伙伴组织起来，并为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服务。
文章来源于领测软件测试网 https://www.ltesting.net/
