我正在使用以下方法进行服务器配置:
envoy proxy
作为网关,后面有一个简单的 python Web 服务器来服务网页和 API 调用。Auth0
对我的用户进行身份验证。OPA
作为授权系统。我使用了类似于
this的
docker-compose.yml
来创建 Envoy 和 OPA 设置。我已经实现了 Auth0 with OPA 安装指南,因此登录后我的加密会话 cookie 中有 Auth0
数据(授权逻辑将在其中运行)。我还找到了像 this 这样有用的资源,它们几乎实现了我正在寻找的流程。
我发现的所有实现、示例和指南都不使用这个确切的配置,而是有一段额外的代码,用于从 cookie 中解码会话数据,并在调用 OPA 服务之前提取用户信息 (
id_token
)。有时作为网络服务器代码的一部分(在我的例子中,这违背了特使网关的目的)。
我感觉非常接近优雅的设计,很少或没有样板代码,并且服务之间的责任没有重叠。我缺少什么?是否有一个 Envoy 过滤器可以在调用 OPA 之前从我应该使用的 cookie 中提取加密会话?也许 OPA 可以从 cookie 中解密会话数据?
我的设计有本质上的错误吗?
查看 ID 令牌在哪里(以及您想要它在哪里!)将帮助您解决这个问题。我认为您需要在进行 OPA 标注之前先获得令牌。
如果您遵循此处的指南https://marketplace.auth0.com/integrations/styra-opa-authorization我相信您最终已经获得了与Python后端中的会话相关联的ID令牌(这很好)将其保留在服务器端的安全实践:) )
如果您希望 ID 令牌由 Envoy Gateway 处理(有效地使 Envoy Gateway 成为您的应用程序后端,有点像 BFF,前端的后端),您将必须执行以下操作:
请记住,这种类型的实现意味着 Envoy Gateway 现在是您的 BFF 以及用户已“登录”的 OIDC 客户端。 EG 现在充当客户端 UI 和(理想情况下)无状态服务器端后端服务之间的中介。
您提到这是一个整体应用程序(即 python Web 服务器既提供 UI 服务,又拥有 UI 随后调用的所有 API) - 我会问自己,使 Envoy Gateway 成为 OIDC 客户端应用程序而不是你的Python应用程序?使用 EG 配置对 OPA 的标注是否比在 Python 应用程序中更容易?也许单体 Python 应用程序不是您的目标架构,因此您想在统一的网关层执行此操作? ;)