固定'；通过'；web服务

本文关键字：服务 web 通过 固定 | 更新日期: 2023-09-27 18:26:20

我目前被分配到一个项目，该项目涉及为稍后开发的应用程序实现后端。该应用程序将在第一个（原型）版本（每个SOAP服务可用）中从另一个平台请求敏感（个人）信息。我们将在未来增加更多的平台。于是出现了以下想法：

APP <---> NEW WEB SERVICE <---> SOAP SERVICE (with the actual data)

我们将新的Web服务放在应用程序和SOAP服务之间，因为SOAP服务是由外部方构建的（并非真正合作）。此外，由于可能出现以下情况，如果我们将有更多的来源来提供数据：

APP <---> NEW WEB SERVICE <---> SOAP SERVICE (with the actual data)
                          <---> WEB SERVICE #2
                          <---> WEB SERVICE #3

由于用户可以登录的web环境已经存在，并且我们的经理希望为应用程序和web环境拥有一个帐户，因此用户的身份验证应该始终由SOAP服务完成。这使新web服务中的身份验证和安全性方面变得复杂。

问题来了，这是否意味着"新web服务"只不过是一个"传递"或"转发"服务？但是我应该如何保护这个"新的网络服务"呢身份验证和会话应由现有的SOAP服务处理

如果"新web服务"提供身份验证之类的解决方案，例如：Oauth或ASP.NET Identity。我对这些选项进行了研究，得出的结论是它们不适用于这种情况。

我的问题是：如何最大限度地利用此新（转发）web服务的可用安全选项？如果我甚至应该添加一个额外的安全层或不

我想出了以下方法，不确定这是否是正确的方法：

  • 使用TLS，1.2版（显然）
  • 为每个用户创建一个api密钥和秘密
  • 使用非对称加密算法加密用户登录详细信息（用户名、密码）

固定'；通过'；web服务

问题的简短答案是否。从web服务进行用户级验证可能会降低整个系统的速度，更重要的是，它不会增加任何价值。与其这样做，您需要做的是确保Web服务是安全的，并且未经授权的方不能访问。为了实现这一点，您可以使用认证、WSS、SSL、防火墙等

让我们假设这个网络服务是在学校里用来发布考试结果的。很明显，学生不应该访问它。所以你必须在应用程序级别控制它，而不是在网络服务级别。你当然可以允许学生向WS发送消息，然后得到WS的回复，说"你没有被授权这样做"。但这会不必要地消耗你的资源。它也会减慢你的系统。

你提到的第二种情况是有效的。有一个中间层是很好的做法，这样您就可以在不更改核心应用程序的情况下满足外部web服务的多个版本。如果外部应用程序不是很可靠，您也可以使用这个中间层来优雅地处理可靠性问题。例如，假设外部服务用于ledger posting。这意味着你的应用程序只会发布一次任何给定的交易。如果失败了，你会怎么办？您可以在中间层中设置重试机制。因此，如果精心设计，中间层实际上可以为您的系统增加更多价值。

相关文章：