我不是任何安全专家,但我赞成创建REST风格的Web服务.
在创建需要使其传输的数据安全的新服务时.我们已经开始讨论哪种方法更安全 - 使用HTTPS的REST或使用WS-Security的SOAP WS.
我的印象是我们可以使用HTTPS进行所有Web服务调用,这种方法是安全的.我看待它的方式是,"如果HTTPS对银行和金融网站来说足够好,那对我来说已经足够了".同样,我不是这个领域的专家,但我认为这些人对这个问题已经相当认真,并且对HTTPS感到满意.
同事不同意并说SOAP和WS-Security是唯一的出路.
网络似乎全面都在这上面.
也许这里的社区可以权衡各自的利弊？谢谢!
HTTPS通过网络保护消息的传输,并为客户端提供有关服务器身份的一些保证.这对您的银行或在线股票经纪人来说非常重要.他们对验证客户端的兴趣不在于计算机的身份,而在于您的身份.因此卡号,用户名,密码等用于验证您的身份.然后通常采取一些预防措施以确保提交没有被篡改,但总的来说,会话中发生的任何事情都被认为是由您发起的.
WS-Security提供机密性和完整性保护,从消息的创建到消费.因此,不是确保通信内容只能由正确的服务器读取,而是确保只能由服务器上的正确进程读取.不是假设安全启动的会话中的所有通信都来自经过身份验证的用户,而是必须对每个通信进行签名.
这里有一个有趣的解释涉及裸体摩托车手:
http://blogs.msdn.com/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked.aspx
因此,WS-Security提供比HTTPS更多的保护,SOAP提供比REST更丰富的API.我的观点是,除非你真的需要额外的功能或保护,否则你应该跳过SOAP和WS-Security的开销.我知道这有点像一个警察,但是关于多少保护实际上是合理的决定(不仅仅是构建起来很酷)的决定需要由那些密切了解问题的人做出.
REST安全性依赖于传输,而SOAP安全性则不然.
REST从底层传输继承安全措施,而SOAP通过WS-Security定义自己的安全措施.
当我们谈论REST,通过HTTP时 - 所有应用的安全措施都是HTTP继承的,这称为传输级安全性.
传输级安全性,仅在线路上保护您的消息 - 一旦它离开线路,消息就不再安全了.
但是,使用WS-Security,它的消息级安全性 - 即使消息离开传输通道,它仍然会受到保护.此外 - 使用消息级安全性,您可以部分加密消息[不是整个消息,而只是您想要的部分] - 但是由于传输级安全性,您无法执行此操作.
WS-Security具有用于身份验证,完整性,机密性和不可否认性的措施,而SSL不支持不可否认性[使用双腿OAuth].
在性能方面,SSL比WS-Security快得多.
谢谢...
从技术上讲,你的措辞方式也不正确,因为SOAP方法的通信不安全,REST方法没有说明对合法用户进行身份验证的事情.
HTTPS可防止攻击者窃听两个系统之间的通信.它还验证主机系统(服务器)实际上是用户打算访问的主机系统.
WS-Security可防止未经授权的应用程序(用户)访问系统.
如果RESTful系统有一种验证用户的方法,而WS-Security的SOAP应用程序正在使用HTTPS,那么两者都是安全的.这只是呈现和访问数据的另一种方式.
查看维基文章:
在点对点情况下,还可以通过使用传输层安全性(TLS)在Web服务上实施机密性和数据完整性,例如,通过https发送消息.
然而,WS-Security解决了在从始发节点发送消息之前保持消息的完整性和机密性的更广泛问题,从而提供所谓的端到端安全性.
那是:
HTTPS是传输层(点对点)安全机制
WS-Security是一个应用程序层(端到端)安全机制.
正如你所说,REST对银行来说足够好,所以应该对你足够好.
安全性有两个主要方面:1)加密和2)身份.
通过SSL/HTTPS传输可通过线路进行加密.但是你还需要确保两台服务器都能确认他们知道他们正在与谁通话.这可以通过SSL客户端证书,共享机密等.
我敢肯定,人们可以说SOAP更"安全",但可能没有任何重要意义.裸体摩托车手的比喻很可爱,但如果准确就意味着整个互联网都是不安全的.
我还没有需要添加评论的代表,或者我会将此添加到Bell的答案中.我认为贝尔在总结这两种方法的顶级优缺点方面做得非常好.您可能需要考虑的其他几个因素:
1)您的客户和您的服务之间的请求是否需要通过需要访问有效负载的中介？如果是这样,那么WS-Security可能更适合.
2)实际上可以使用SSL来使用称为相互身份验证的功能为服务器提供有关客户端身份的保证.但是,由于配置的复杂性,这在一些非常专业的方案之外没有得到很多用处.所以Bell是正确的,WS-Sec在这里更合适.
3)SSL通常可能有点像设置和维护(即使在更简单的配置中),主要是由于证书管理问题.让一个知道如何为您的平台做到这一点的人将是一个很大的优势.
4)如果您可能需要进行某种形式的凭证映射或身份联合,那么WS-Sec可能值得开销.并不是说你不能用REST做到这一点,你只需要较少的结构来帮助你.
5)将所有WS-Security goop放在客户端的正确位置可能比你想象的更痛苦.
最后虽然它确实依赖于很多我们不太可能知道的事情.在大多数情况下,我会说任何一种方法都是"足够安全",所以这不应该是主要的决定因素.
Brace yourself, here there's another coming :-)
今天我不得不向我的女朋友解释WS-Security与HTTPS相比的表现力.她是一名计算机科学家,所以即使她不知道所有的XML mumbo jumbo,她理解(也许比我更好)加密或签名意味着什么.然而,我想要一个强大的形象,这可以让她真正理解什么是有用的东西,而不是它们如何实现(稍后,她没有逃避它:-)).
所以就是这样.假设你是赤身裸体,你必须把你的摩托车开到某个目的地.在(A)案例中,你通过一个透明的隧道:你唯一没有因淫秽行为而被捕的希望是没有人在寻找.这不是你可以提出的最安全的策略......(注意前额的汗水:-)).这相当于一个明确的POST,当我说"等效"时,我的意思是.在(B)案例中,您的情况会更好.隧道是不透明的,所以只要你进入它,你的公共记录是安全的.但是,这仍然不是最好的情况.您仍然必须离开家并到达隧道入口,一旦在隧道外,您可能必须下车并在某处行走......这适用于HTTPS.确实,你的信息在跨越最大的鸿沟时是安全的:但是一旦你在另一边传递它,你就不知道在到达处理数据的真实点之前需要经过多少个阶段.当然,所有这些阶段都可以使用与HTTP不同的东西:例如,传统的MSMQ可以缓冲无法立即提供的请求.如果有人潜伏在预处理过程中,会发生什么？嗯.(读这个"嗯"就像Morpheus在句子末尾所说的那样"你认为你呼吸的是空气吗？").这个比喻中的完整解决方案(c)非常简单:在自己身上穿一些衣服,尤其是摩托车上的头盔!因此,您可以安全地四处走动,而不必依赖于环境的不透明性.这个比喻很有希望清楚:无论平均水平还是周围的基础设施,衣服都随身携带,就像消息级安全一样.此外,你可以决定覆盖一个部分,但是可以揭示另一个部分(你可以在个人的基础上做到这一点:机场安全可以让你的夹克和鞋脱落,而你的医生可能有更高的访问级别),但要记住短袖衬衫是即使你为你的二头肌感到骄傲也是不好的做法:-)(更好的马球或T恤).
我很高兴地说她明白了!我不得不说衣服的比喻非常强大:我很想用它来介绍政策的概念(迪斯科俱乐部不会让你穿运动鞋;你不能去银行取钱买你的内衣虽然这是完全可以接受的外观,同时在冲浪中平衡自己;等等)但我认为一个下午就够了;-)
建筑 - 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)只有一层确保:
连接的服务器提供证明其身份的证书(尽管这可能是通过DNS中毒欺骗).
通信层是加密的(没有窃听).
WS-Security和相关标准/实现使用PKI:
证明客户的身份.
证明邮件未在传输中修改(MITM).
允许服务器对客户端进行身份验证/授权.
当客户端(呼叫者)的身份对于知道是否应该被授权从服务接收这样的数据时,最后一点对于服务请求是重要的.标准SSL是单向(服务器)身份验证,不会识别客户端.
答案实际上取决于您的具体要求.
例如,您是否需要保护您的Web消息或不需要保密,您只需要对最终方进行身份验证并确保消息完整性？如果是这种情况 - 而且通常是Web服务 - HTTPS可能是错误的.
但是 - 根据我的经验 - 不要忽视您正在构建的系统的复杂性.不仅HTTPS更容易正确部署,而且依赖于传输层安全性的应用程序更容易调试(通过纯HTTP).
祝好运.
REST over HTTPS只要API提供程序在服务器端实现授权,它就是一种安全的方法.在Web应用程序的情况下,我们所做的是通过HTTPS和一些身份验证/授权访问Web应用程序,传统上Web应用程序没有安全问题,然后Restful API也会毫无问题地解决安全问题!
京公网安备 11010802040832号 | 京ICP备19059560号-6 