Web应用安全体系结构

Question

我有一个JavaScript驱动的REST服务器与PostgreSQL数据库连接，Java中的Spring使用JavaScript(现在是浏览器，但在将来也使用移动应用程序)为从REST到客户端的内容提供服务。

我读过许多文章和主题，都是如何保护REST的，但我还没有做出最后的决定。我不想拥有基本的授权，因为这是没有意义的，因为我需要将凭证存储在JavaScript中，这样任何进入网页和开发人员控制台的人都可以轻松地访问和读取凭证。我不想向最终用户显示任何凭据，所以我不能将它们保存在客户端。

我读过很多关于JWT的文章，几乎决定实现它，但是我听说它有一些缺点，从那时起我就不太确定它是否是我想要选择的选项。我知道还有oAuth 1.0或oAuth 2.0，但我不知道我是否想要这么复杂的东西。我还想将散列的用户凭据存储在我自己的数据库中，以便不依赖于任何其他凭据提供商，如社交媒体或谷歌。

现在，我正在我的web服务器上创建另一个层作为代理，希望它将允许我使用Spring Security在这个代理级别上对用户进行身份验证，并拥有某种类型或cookie或其他东西来进行身份验证，但我不太确定它是否可以这样做，它会增加响应时间，增加复杂性，并需要我为这些端点编写控制器方法。我现在的架构如下：

客户端(浏览器) -> Webserver -> REST服务器-> db

我还拒绝了所有外部连接，并且只允许本地主机访问tomcat级别上的REST，因此我只能在web服务器上实现安全级别，允许在web服务器和REST之间自由传输信息，因为无论如何都无法访问它。

Web服务器和REST与Tomcat实例运行在同一台服务器上。

我也不太确定这种架构是否允许我通过web服务器认证移动应用程序客户端。

我非常感谢你在这件事上对我提出的任何建议。我在保安方面不是很有经验，所以我有点不知所措。这种架构是否有任何意义，或者我应该直接从任何类型的客户端询问REST，无论是来自不同IP的网页还是移动应用程序，并且仅限于安全Rest？如果我想保护我的网页或移动应用程序的部分子页面，那应该是一个完全不同的层吗？

谢谢你的帮助。

Answer 1

您已经通过了OAuth、JWT令牌等等。如果您不想使用它们，那么您可以创建您的own token based authentication system。(例如“TokenHandler”)。

这个TokenHandler将如何工作?

TokenHandler就像一个网关服务器，您的每个REST请求都将通过这个服务器应用程序进行路由。因此，您将使用authToken in header来解决移动和web应用程序调用的混乱。此服务器应用程序的主要责任是接受令牌并对维护所有令牌细节的数据库进行验证。此DB将包含有关时间戳的信息，该时间戳是最后一次使用令牌进行验证，以决定您的验证规则。

如何生成令牌?令牌可以是任意64位数字字母数字字符串，并将在每次登录活动期间在DB中生成和更新。登录webservice在响应体中返回此令牌。

，什么是验证规则?，它可以取决于您的业务逻辑。我宁愿保持15分钟的活动会话窗口。意味着如果您访问webservice，您将得到15分钟的活动窗口。如果您连续15分钟没有访问任何服务，那么从第16分钟开始，您将需要再次登录才能访问进一步的呼叫。这部分可以根据要求进行修改。

客户端将如何处理?客户端将存储此令牌，并在每个请求调用中传递此令牌。令牌处理程序将验证它的请求并将其重定向到应用服务器。因此，您的一个令牌处理程序可以用于多个应用程序服务器的服务器身份验证。这可以通过应用程序端点标识来实现。

如果您有任何问题或建议，我想进一步讨论。

Answer 2

为您的用例使用API架构模式- http://microservices.io/patterns/apigateway.html。

API网关(问题中的all服务器)可以作为所有桌面/移动客户端的单一入口点。您可以使用会话cookie或jwt在网关上验证客户端。

关于网关和微服务之间的身份验证，以及微服务之间的身份验证，我建议相互的SSL-https://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication。如果您使用的是spring引导，这可能会有所帮助- http://www.opencodez.com/java/implement-2-way-authentication-using-ssl.htm

IP白列表方法的问题在于，它不太适合云体系结构，因为IP可能会随着每台服务器的重新启动而改变。即使您使用的是专用IP，您也应该小心地确保与SSL/TLS的通信安全，否则攻击者可以很容易地嗅探到您的流量。