通过反向代理保护不同类型的不安全应用程序

Question

我目前正在处理一个具有复杂要求的项目，对于正在考虑的解决方案我不满意。

主要思想是保护现有应用程序（本身不包括安全性）而不对其进行修改。这些应用程序不能从外部访问，只能通过反向代理（OpenResty）进行访问。

用户无权访问所有应用程序，而识别用户的解决方案是Keycloak。

主要成分是：

• 一个有角度的门户：入口点
• 一个反向代理，可以在所选应用程序上重定向用户
• IAM：密钥斗篷
• 所有可用的应用程序

this schema explain it

这个想法是：

• 用户单击Keycloak并登录，并使用包含其角色（他有权访问的应用程序）的访问令牌（JWT）返回门户。
• 用户单击门户网站上的应用程序，然后通过反向代理将其重定向到目标应用程序
• 反向代理检查令牌（exp，iss和角色）的有效性

我知道这不是在应用程序之间执行某些SSO的正确方法，但是这里的要求是，必须编辑受未保护的应用程序保护，否则必须由前期系统进行保护（反向代理）这里）

我的问题是：好的，这将对第一次调用有效，因为用户在门户网站上拥有他的JWT令牌，并首次使用它命中了该应用程序，但是当用户单击该应用程序中的链接之后。 。没有更多的令牌了。这种架构可以很好地保护Web应用程序的REST API，对我来说有点不确定。

Answer 1

尝试使用github.com/gambol99/keycloak-proxy。它将令牌存储在cookie中，这对于Web应用程序是更好的选择。

！！！警告：我猜任何身份验证代理都只能使用授权代码流，但是对于单页应用程序（角度），建议使用隐式流。这实际上取决于您的Angular应用程序是什么。分析秒。为了安全起见，首先要考虑利弊。

Answer 2

通常，您将使用反向代理服务器来处理用户身份验证，而不是先登录到密钥库。

流程如下：

1. 用户访问门户。
2. 门户网站通过反向代理将用户重定向到应用程序。
3. 反向代理将首先将用户重定向到keycloak 身份验证，并在浏览器和 反向代理服务器。
4. 反向代理转发请求到您的应用程序 服务器。
5. 对于所有后续请求，用户始终通过反向代理服务器。