我目前被分配到一个项目,该项目涉及为将在稍后阶段开发的应用程序实现后端。该应用程序将在第一个(原型)版本(每个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
由于用户可以登录的网络环境已经存在且我们的经理想要为应用程序和网络环境设置一个帐户,因此用户的身份验证应始终由SOAP服务完成。这使新Web服务中的身份验证和安全性方面变得复杂。
问题是,如果这意味着新的网络服务&#39;只不过是通过&#39;或者&#39;转发&#39;服务?但是,我应该如何确保这个新的网络服务&#39;? 身份验证和sesions应由现有的SOAP服务处理。
如果是新的网络服务&#39;提供身份验证等解决方案,如:Oauth或ASP.NET Identity。我已经对这些选项进行了研究,并得出结论,他们并不适用于这种情况。
我的问题是:如何充分利用此新(转发)Web服务的可用安全选项?如果我甚至应该添加额外的安全层。
我想出了以下内容,不确定这是否是正确的方法:
答案 0 :(得分:2)
您的问题的简短回答是否。从Web服务进行用户级验证可能会降低整个系统的速度,更重要的是它不会增加任何值。您需要做的是确保Web服务是安全的,并且未经授权的各方无法访问,而不是这样做。为此,您可以使用认证,WSS,SSL,防火墙等。
让我们假设这个网络服务在学校中用于发布考试成绩。显然学生应该无法访问它。因此,您必须在应用程序级别控制它,而不是在Web服务级别。您可以允许学生向WS发送消息,然后从WS获得响应,说明&#34;您无权执行此操作&#34;。但它会不必要地消耗你的资源。它也会降低你的系统速度。
您提到的第二种情况是有效的。拥有中间层是一种很好的做法,这样您就可以满足多个版本的外部Web服务,而无需更改核心应用程序。如果外部应用程序不是非常可靠,您还可以使用此中间层正常处理可靠性问题。例如,假设外部服务用于ledger posting
。这意味着您的应用程序将仅发布一次任何给定的事务。如果失败你会怎么做?您可以在中间层使用重试机制。因此,如果仔细设计,中间层实际上可以为您的系统增加更多价值。