安全Web服务:HTTPS上的REST与SOAP+WS安全性。哪个更好?[闭门]

HTTPS确保消息在网络上的传输安全,并向客户端提供有关服务器身份的一些保证。这对你的银行或在线股票经纪人来说很重要。他们对验证客户端的兴趣不在于计算机的身份,而在于您的身份。所以卡号、用户名、密码等都是用来认证你的。然后通常会采取一些预防措施,以确保提交的内容没有被篡改,但总的来说,会话中发生的任何事情都被视为是您发起的。

WS-Security提供了从消息创建到消息使用的机密性和完整性保护。因此,与其确保通信内容只能由正确的服务器读取,不如确保通信内容只能由服务器上正确的进程读取。与假设安全启动会话中的所有通信都来自经过身份验证的用户不同,每个通信都必须进行签名。

https://docs.microsoft.com/archive/blogs/vbertocci/end-to-end-security-or-why-you-shouldnt-drive-your-motorcycle-naked

因此,WS-Security提供了比HTTPS更多的保护,而SOAP提供了比REST更丰富的API。我的观点是,除非您真的需要额外的特性或保护,否则您应该跳过SOAP和WS-Security的开销。我知道这是一种逃避,但关于多少保护是真正合理的(而不仅仅是建造什么很酷)的决定需要由那些密切了解问题的人做出。

REST安全性依赖于传输,而SOAP安全性则不依赖于传输。

REST从底层传输继承安全措施,而SOAP通过WS-security定义自己的安全措施。

传输级别的安全性,仅当邮件在线路上时才对其进行保护-一旦离开线路,邮件就不再安全。

但是,使用WS-Security,它的消息级安全性—即使消息离开传输通道,它仍将受到保护。此外,使用消息级安全性,您可以部分加密消息[不是整个消息,而是只加密您想要的部分]——但使用传输级安全性,您无法做到这一点。

WS-Security具有身份验证、完整性、机密性和不可否认性的措施,而SSL不支持不可否认性[它支持两条腿的OAuth]。

谢谢

从技术上讲,这两种方法的措辞都不正确,因为SOAP方法的通信不安全,而REST方法没有说明任何有关验证合法用户的内容。

HTTPS可防止攻击者 eavesdropping

WS-Security防止未经授权的应用程序(用户)访问系统。

如果RESTful系统有一种对用户进行身份验证的方法,并且具有WS-Security的SOAP应用程序使用HTTPS,那么实际上两者都是安全的。这只是表示和访问数据的另一种方式。

见 wiki

在点对点情况下,还可以通过使用传输层安全性(TLS),例如通过https发送消息,在Web服务上强制实现机密性和数据完整性。

即:

• HTTPS是一种传输层(点对点)安全机制
• WS-Security是一种应用层(端到端)安全机制。

正如你们所说的,休息对银行来说已经足够了,所以对你们来说也应该足够了。

安全性有两个主要方面:1)加密和2)身份。

我相信有人可以证明SOAP是“更安全的”,但可能没有任何意义。裸体摩托车手的比喻很可爱,但如果准确的话,就意味着整个互联网是不安全的。

我还没有代表需要添加评论,否则我会在贝尔的回答中添加这一点。我认为贝尔在总结这两种方法的优缺点方面做得非常好。您可能需要考虑的其他几个因素:

1) 客户机和服务之间的请求是否需要通过需要访问有效负载的中介?如果是这样,那么WS-Security可能更合适。

2) 实际上,可以使用SSL,通过一种称为相互身份验证的功能,向服务器提供有关客户端身份的保证。但是,由于配置的复杂性,这在一些非常特殊的场景之外没有太多用处。所以贝尔是对的,WS-Sec更适合这里。

3) 通常,SSL的设置和维护(即使在更简单的配置中)会有点困难,这主要是由于证书管理问题。有一个知道如何为你的平台做到这一点的人将是一个巨大的优势。

4) 如果您可能需要进行某种形式的凭证映射或身份联合,那么WS-Sec可能值得为此付出代价。并不是说你不能用REST来做这件事,你只是有更少的结构来帮助你。

5) 将所有WS-Security问题放到客户端的正确位置可能比您想象的更痛苦。

但最终,这确实取决于很多我们不太可能知道的事情。在大多数情况下,我会说这两种方法都“足够安全”,因此这不应该是主要的决定因素。

Brace yourself, here there's another coming :-)

事情是这样的。假设你赤身裸体,你必须驾驶摩托车去某个目的地。 在(A)案例中,你通过了一条透明的隧道:你不因猥亵行为被捕的唯一希望是没有人在看。这并不是你能想出的最安全的策略。。。(注意男人额头上的汗珠:-)。这相当于一篇清晰的帖子,当我说“等效”时,我是认真的。 在(B)种情况下,你的处境更好。隧道是不透明的,所以只要你进入它,你的公开记录是安全的。然而,这仍然不是最好的情况。你仍然必须离开家,到达隧道入口,一旦出了隧道,你可能不得不下车,走到某个地方。。。这就是HTTPS。诚然,您的消息在跨越最大鸿沟时是安全的:但一旦您在另一边传递消息,您就不知道在到达数据处理的真正点之前,它需要经过多少阶段。当然,所有这些阶段都可以使用与HTTP不同的东西:例如,一个经典的MSMQ,它缓冲不能立即提供服务的请求。如果有人在预处理过程中隐藏了你的数据,会发生什么?嗯(把这个“嗯”读成莫菲斯在“你认为你呼吸的是空气吗?”)这句话末尾说的那个。

我很高兴地说,她说得对!我不得不说,衣服的比喻非常有力:我很想用它来介绍政策的概念(迪斯科俱乐部不允许你穿运动鞋;你不能穿着内衣去银行取钱,而在冲浪时保持平衡是完全可以接受的样子;等等)但我认为一个下午就足够了;-)

架构-WS,疯狂的想法

http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked.aspx

我每天都在这一领域工作,因此我想总结一下对此的好评,以期结束这一问题:

SSL(HTTP/s)只是一个层,确保:

1. 连接到的服务器提供一个证书,证明其 身份(尽管这可以通过DNS中毒进行欺骗)。

WS-Security和相关标准/实施使用的PKI:

2. 证明邮件未被修改 运输中(MITM)。
3. 允许服务器对服务器进行身份验证/授权

最后一点对于服务请求很重要,因为客户机(调用者)的身份对于了解他们是否应该被授权从服务接收此类数据至关重要。 标准SSL是单向(服务器)身份验证,不识别客户端。

例如,您是否需要保护您的web消息,或者不需要保密,您只需要验证最终方并确保消息的完整性?如果是这样的话——web服务经常是这样——HTTPS可能是错误的选择。

祝你好运

只要API提供程序在服务器端实现授权,HTTPS上的REST应该是一种安全的方法。在web应用程序的情况下,我们所做的是通过HTTPS和一些身份验证/授权访问web应用程序,传统的web应用程序没有安全问题,那么Restful API也会毫无问题地解决安全问题!

如果RESTFul调用在HTTP请求的Html正文中来回发送嵌入的XML消息,那么在使用HTTP提供的任何安全功能(如SSL/TLS加密)的同时,您应该能够在XML消息中获得WS-Security的所有好处,如XML加密、证书等。