微服务到微服务调用，来自队列消息的授权 [英] Microservice to Microservice calls, authorization from a queue message

问题描述

上下文:我正在创建一个云平台，以支持使用 SSO 的多个应用程序.我通过 Keycloak Spring Security Adapter 使用 Keycloak 进行身份验证 和 Netflix Zuul 进行授权(API 网关).

每个微服务都需要一个 Authorization 标头，其中包含一个有效的 JWT，它将使用用户名(子)来处理请求.每个微服务到微服务的调用都应该首先通过 Netflix Zuul，传递 Authorization 标头以维护无状态验证.该策略允许每个微服务知道谁是间接调用微服务的用户(子).

问题/问题 1:如果从队列消息中调用微服务会发生什么?我的一个想法是将与消息 + userInfo 相关的信息存储在队列中，并创建一个专用的微服务来处理这种消息，通过这种方法，这个特殊的微服务应该从队列中读取 userInfo 并处理消息.

<块引用>

更新 1:根据来自另一个论坛的电子邮件回复，将 JWT 存储在队列中并不是一个好主意，因为它很容易被挖掘.

问题/问题 2: 但是，如果之前的特殊微服务想要调用另一个期望在标头中接收 JWT 的普通微服务，会发生什么?这个特殊的微服务是否应该自己创建一个JWT来模拟用户并能够调用常规微服务?

我认为的另一个解决方案是将原始 JWT 存储在队列中，但是，如果队列稍后调用特殊微服务会发生什么?就在 JWT 不再有效(过期)并且被调用的微服务将拒绝请求之后?

可能的解决方案:(根据 João Angelo 的讨论更新，见下文)

<块引用>

我应该对来自我的用户(授权代码流)和我的服务(客户端凭据授予)的请求进行身份验证，这两个请求都应该在负载中包含用户信息.当它来自用户的请求时，我需要验证有效负载用户信息是否与 JWT 声明匹配.当请求来自服务时，我只需要信任该服务(只要它在我的控制之下).

非常感谢您的帮助.谢谢.

解决方案

免责声明:我从未使用过 Keycloak，但标签 wiki 说它符合 OAuth2，所以我相信这些信息.p><小时>

在一个非常高级的视图中，您似乎有两个要求:

1. 验证最终用户在使用您的系统时触发的操作.
2. 验证您的系统在未知时间触发的操作，并且最终用户无需在线.

您已经遇到了第一个，依靠基于令牌的身份验证系统，第二点我会做完全相同的事情，唯一的区别是令牌将使用OAuth2 客户端凭据授予，而不是针对存在最终用户的场景的其他授予.

(来源:客户端凭据授予)

在您的情况下，Keycloak 将扮演 Auth0 的角色，您的客户端应用程序是微服务，可以维护用于在授权服务器中对自己进行身份验证并获取访问令牌的客户端机密.

需要记住的一点是，如果您的系统依赖于 sub 声明的功能远不止身份验证和授权，那么您可能需要进行一些调整.例如，我见过执行操作 A 需要知道它针对用户 X 和 Y 的系统，但操作的有效负载只接收到用户 Y 并假设用户 X 是当前经过身份验证的主体.这在一切都是同步的情况下工作得很好，但是仅仅通过切换有效负载来指定两个用户将意味着该操作可以由系统身份验证的主体异步完成.

Context: I'm creating a cloud platform to support multiple applications with SSO. I'm using Keycloak for authentication and Netflix Zuul for authorization (API Gateway) thru Keycloak Spring Security Adapter.

Each microservice expect an Authorization header, which contains a valid JWT, from which it will take the username (sub) to process the request. Each microservice-to-microservice call should go thru Netflix Zuul first, passing the Authorization header to maintain a stateless validation. That strategy allow to every microservice to know who is the user (sub) who is invoking the microservice indirectly.

Problem/Question 1: What happens if a microservice is invoked from a queue message? One idea that I had is to storage in the queue the information related to the message + userInfo, and, create a dedicated microservice to process that kind of messages, with that approach this special microservice should read the userInfo from the queue and process the message.

UPDATE 1: Per an email reply from another forum, storing the JWT in a queue isn't a good idea, since it could be mined easily.

Problem/Question 2: But, what happens if the previous special microservice wants to call another normal microservice which expect to receive a JWT in a header? Should this special microservice create by himself a JWT to impersonate the user and be able to call the regular microservices?

Another solution that I thought was to storage the original JWT in the queue, but, what happens if the queue calls to the special microservice later? Just after the JWT is not valid anymore (it expired) and the microservice called will reject the request?

Possible solutions: (Updated per João Angelo discussion, see below)

I should authenticate the requests from my users (Authorization code flow) and my services (Client credentials grant), both requests should contain user information in the payload. When the request it comes from the user, I need to validate that the payload user info match with the JWT claims. When the request comes from a service, I just need to trust in that service (as long as it is under my control).

I will appreciate very much your help. Thanks.

解决方案

Disclaimer: I never used Keycloak, but the tag wiki says it's compliant with OAuth2 so I'll trust that information.

---

At a really high-level view, you seem to have two requirements:

1. authenticate actions triggered by an end user while he's using your system.
2. authenticate actions triggered by your system at an unknown time and where there is no requirement for a end-user to be online.

You already met the first one, by relying on a token-based authentication system and I would do exactly the same for the second point, the only difference would be that the tokens would be issued to your system using the OAuth2 client credentials grant instead of the other grants that are targeted at scenarios where there is an end-user.

(source: Client Credentials Grant)

In your case, Keycloak would play the role of Auth0 and your client applications are microservices which can maintain client secrets used to authenticate themselves in the authorization server and obtain access tokens.

One thing to have in mind is that if your system relies on the sub claim for much more than authentication and authorization then you may need to make some adjustments. For example, I've seen systems where performing action A required to know that it was targeted at user X and Y, but the payload for the action only received user Y and assumed user X was the current authenticated principal. This works fine when everything is synchronous, but by merely switching the payload to specify both users would mean that the action could be done asynchronously by a system authenticated principal.

这篇关于微服务到微服务调用，来自队列消息的授权的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！