确保同一托管环境中受信任服务器之间的通信安全
我在一家开发软件产品的公司工作，该产品可以处理银行交易并让用户深入了解他/她的支出。我们的客户（通常是银行）将该产品集成到他们的网上银行中。
我有一个关于确保网上银行与我们的系统之间通信安全的问题。在问问题之前，我想先向您介绍一些背景知识。
银行通常会将我们的系统安装在其托管环境中的一组服务器上。
我们提供多种集成方式：
- Web 服务 - 在这种情况下，银行将调用服务器上的一组 REST 服务，然后生成包含结果的网页（在服务器端） ）。
- iframe - 在这种情况下，银行将在其网上银行网页中嵌入 iframe。 iframe 包含直接从我们的 Web 应用程序呈现的网页。
- 内联小部件 - 在这种情况下，银行将在其页面上嵌入 JavaScript 引用。当文档加载时，JavaScript 小部件将使用 AJAX 调用自行呈现。它们与银行服务器上的代理进行通信，而银行服务器又与我们的网络应用程序进行通信。
我们目前有一个自定义解决方案，可以为用户生成和签署安全令牌，并通过请求传递这些令牌。
但由于银行有非常严格的安全政策，如果我们使用已知且可信的安全协议进行通信，他们会感觉更好。这是我们想要解决的一个大问题。
所以问题是，哪种协议最适合我上面列出的集成用例？有大量的单点登录标准以及 SAML、oauth 等解决方案。我感觉这些解决方案对于我的情况来说可能有点过分了。
我想找到一个简单的解决方案。由于服务器将在同一托管环境中并行运行，并且完全相互信任，因此最终用户无需授权其中之一（或在之间重定向，单击按钮即可访问应用程序）。
也就是说，安全协议不应要求最终用户的任何干预。最终用户只需登录他/她的网上银行，并通过安全通信即可访问我们网络服务器的数据。
那么...有什么建议吗？
多谢！
奥格
I work for a company that develops a software product that processes bank transactions and gives the user insight into his/her spending. Our customers (usually banks) integrate the product into their online banks.
I have a question about securing the communication between the online bank, and our system. Before I ask the question, I want to give you some background.
The bank will usually install our system on a set of servers in their hosting environment.
We offer a number of ways to integrate:
- Web services - In this case the bank will make calls to a set of REST services on the server, and then generate a webpage with the results (on the server side).
- Iframes - In this case the bank will embed iframes in their online bank webpages. The iframes contain webpages rendered directly from our web application.
- Inline widgets - In this case the bank will embed JavaScript references on their pages. When the document loads, the JavaScript widgets will render themselves, using AJAX calls. They communicate with a proxy on the bank server, which in turn communicates with our webapp.
We currently have a custom solution where we generate and sign security tokens for the users, and pass these with the requests.
But as banks have very strict security policies, they would feel better with us using a known and trusted security protocol for the communication. It is a big concern, which we want to address.
So the question is, which protocol is best suited for the integration use cases I listed above? There is a plethora of single-sign-on standards out there, and solutions like SAML, oauth, etc. I get the feeling that these solutions might be an overkill for my situation.
I want to find a solution that is simple. As the servers will run side by side in the same hosting environment, and trust each other completely, there is no need for the end user to authorize one or the other (or being redirected between, clicking buttons to give access to the app).
That is, the security protocol should not require any intervention from the end user. The end user simply logs into his/her online bank, and via secure communication has access to the data from our web server.
So...any suggestions?
Thanks a lot!
OGG
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
经过深思熟虑，我们决定使用 2-legged OAuth（在线银行使用消费者密钥和消费者秘密来签署对我们应用程序的请求）。
OAuth 签名可以放在请求标头中，也可以放在请求参数中。它很好地解决了我们的问题，因为可以对 REST 请求进行签名，并且 IFRAME src URL-s 也可以进行签名（所有通信都通过 HTTPS 进行）。
对于那些感兴趣的人，有一些参考资料：
本文展示了如何将 OAuth 与 IFRAME 结合使用：http ://developer.tradeshift.com/blog/cross-site-user-verification/
本文提到了 OAuth 的一些安全问题以及如何应对威胁：http://software-security.sans.org/blog/2011/03/07/oauth -授权攻击安全实施
After some deliberation, we decided to use 2-legged OAuth (online bank uses consumer key and consumer secret to sign requests to our app).
OAuth signature can either be put in a request header, or request parameters. It nicely solves our problem, as the REST requests can be signed, and the IFRAME src URL-s can also be signed (all communication is over HTTPS).
For those interested, a couple of references:
This article shows using OAuth with IFRAMEs: http://developer.tradeshift.com/blog/cross-site-user-verification/
This article mentiones some security issues with OAuth, and how threats can countered: http://software-security.sans.org/blog/2011/03/07/oauth-authorization-attacks-secure-implementation