移动应用程序基于 Web 或 SOAP 的集成

发布于 2024-12-03 22:09:27 字数 1316 浏览 0 评论 0原文

我正在寻找企业移动应用程序架构的一些输入。它适用于拥有数百个现有的基于 SOAP 的 Web 服务的大型组织,供基于 Web 的应用程序使用。我们使用服务帐户进行应用程序到 Web 服务的身份验证和授权(应用程序 N 具有特定的用户名和密码与 Web 服务 N 进行通信)。这些应用程序托管在 Android 市场和 iTunes(iPad 和 Android 应用程序)中。我们还需要为这些移动应用程序提供基于 SAML 的 SSO(目前不支持 OAuth)。

我提出了一种基于 Web 的集成方法,用于使用这些应用程序中的这些 Web 服务以及代理服务器来拦截来自移动应用程序的这些请求。因此,流程是:

  1. 移动应用程序使用 HTTP 和 JSON 与代理服务器进行通信。所有 SAML SSO 工作流程均由移动应用程序、服务提供商(代理服务器)和身份提供商服务器处理。
  2. 代理服务器使用服务帐户与 Web 服务进行通信,并将请求和响应编组和解组为 JSON。

这种方法的优点是:

  1. 由于基于 Web 的方法而进行跨平台移动应用程序开发,如下所示: 在跨平台方面已经做了哪些工作平台移动开发?
  2. 由于 HTTP 协议(​​而不是 SOAP),基于 SAML 的安全集成更容易。

我还看到该项目的 SOAP 存在以下问题:

  1. 在 SOAP 请求中使用 SAML 身份验证的一些技巧?
  2. 由于 Web 服务身份验证是使用服务帐户完成的,因此您需要在移动应用程序的代码中嵌入 Web 服务的密码,我将其视为安全问题与移动应用程序
  3. 的 JSON 相比,编组和取消编组 SOAP 请求和响应的成本较高设备。
  4. 由于我们需要在设备中嵌入秘密(密码)才能与网络服务通信,这是一个安全问题。 http://www .performantdesign.com/2009/09/03/facebook-iphone-session-proxy-in-php-fbsession-getsessionproxy/ 所以这个应用程序服务器充当会话代理。

这有道理吗?这种方法有什么缺陷吗?

预先非常感谢

I am looking for some inputs for an enterprise mobile application architecture. It is a for large organization with with hundreds of existing SOAP based web-services for consumption by web based application. We use service accounts for application to web-service authentication and authorization (Application-N with a specific username and password to communicate with web-service-N). These apps are hosted at Android market and iTunes (iPad and Android apps). We also have a need of SAML based SSO for these mobile apps (OAuth is not entertained at the moment).

I am proposing a web-based integration approach for consumption of these web-services from these apps along with a proxy server to intercept these requests from mobile apps. So, the flow would be:

  1. Mobile app communicates with proxy server using HTTP and JSON.All the SAML SSO workflow is handled by mobile app, service provider which is proxy server and identity provider server.
  2. Proxy server communicates with web-services using service account and marshalls and unmarshalls the requests and responses to JSON.

The advantage with this approach is:

  1. Cross platform mobile application development due web-based approach as pointed by:
    What work has been done on cross-platform mobile development?
  2. Easier SAML based security integration due to HTTP protocol as opposed to SOAP.

I also see the following issues with SOAP for this project:

  1. Some hack to use the SAML authentication within SOAP request?
  2. Since web-service authentication is done using service accounts, so you need to embed password for the web-service with mobile application's code, which I see it as security issues
  3. Marshalling and un-marshalling SOAP requests and response is expensive compared to JSON for mobile device.
  4. Since we need to embed the secret(password) in device to communicate with web-service, which is a security issue. http://www.performantdesign.com/2009/09/03/facebook-iphone-session-proxy-in-php-fbsession-getsessionproxy/ So this app-server acts as session proxy.

Is this makes sense? Any flaws with this approach?

Many thanks in advance

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

咽泪装欢 2024-12-10 22:09:27

实际上,您选择的协议不会影响开发人员要实现的漏洞或设计缺陷的数量。您可以使用任何技术构建非常安全的 API。

SOAP 的真正优势在于 WSDL 文件可用于针对服务构建自动化安全测试。因此,当开发人员犯错误时,您可以检测到。在发布新版本的 API 之前,请确保使用 WSFuzzer

SOAP 还具有内置于协议中的加密和身份验证等功能,因此您无需重新设计。

In all reality the protocol that you choose isn't going to affect the number of vulnerabilities or design flaws a developer is going to implement. You can build a very secure API using any technolgoy.

The real strength of SOAP is that the WSDL file can be used to build automated security tests against the service. So when the developer makes a mistake, you can detect it. Before you release a new version of the API make sure test the code with something like WSFuzzer.

SOAP also has features such as encryption and authentication built into the protocol so you don't have to reinvent the wheal.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文