微服务到微服务的调用，来自队列消息的授权 [英] Microservice to Microservice calls, authorization from a queue message
问题描述
上下文:我正在创建一个云平台，以通过SSO支持多个应用程序.我正在通过 Keycloak Spring Security适配器使用 Keycloak进行身份验证和 Netflix Zuul进行授权(API网关).
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.
每个微服务都期望一个Authorization标头，其中包含一个有效的JWT，它将使用用户名(子)来处理请求.每个微服务到微服务的调用都应首先通过Netflix Zuul，并传递Authorization标头以维护无状态验证.该策略允许每个微服务知道谁是间接调用微服务的用户(子).
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.
问题/问题1:如果从队列消息中调用微服务会怎样?我的一个想法是将与消息+ userInfo有关的信息存储在队列中，并创建专用的微服务来处理此类消息，通过这种方法，这种特殊的微服务应从队列中读取userInfo并处理消息
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.
更新1:根据另一个论坛的电子邮件回复，将JWT存储在队列中并不是一个好主意，因为它很容易被挖掘.
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.
问题/问题2:但是，如果以前的特殊微服务想要调用另一个希望在标头中接收JWT的普通微服务，会发生什么情况?这种特殊的微服务是否应该自己创建一个JWT来模拟用户并能够调用常规微服务?
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?
我认为的另一种解决方案是将原始JWT存储在队列中，但是，如果队列稍后调用特殊的微服务会发生什么呢?就在JWT不再有效(过期)之后，调用的微服务会拒绝该请求吗?
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?
可能的解决方案:(根据JoãoAngelo的讨论进行了更新，请参见下文)
Possible solutions: (Updated per João Angelo discussion, see below)
我应该对用户(授权代码流)和服务(客户端凭据授予)的请求进行身份验证，这两个请求都应在有效负载中包含用户信息.当请求来自用户时，我需要验证有效负载用户信息是否与JWT声明匹配.当请求来自服务时，我只需要信任该服务(只要它在我的控制之下)即可.
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.
推荐答案
免责声明:我从未使用过Keycloak，但是标签Wiki表示它符合OAuth2，因此我相信这些信息.
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:
- 验证最终用户在使用您的系统时触发的操作.
- 在未知时间且不需要最终用户在线的情况下，对系统触发的操作进行身份验证.
您已经通过使用基于令牌的身份验证系统遇到了第一个，并且第二点我将完全相同，唯一的不同是令牌将使用OAuth2客户端凭据授予，而不是针对最终用户存在的情况的其他授予.
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.
(来源:客户凭据授予 )
在您的情况下，Keycloak将扮演Auth0的角色，并且您的客户端应用程序是微服务，可以维护用于在授权服务器中进行身份验证并获取访问令牌的客户端机密.
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.
要记住的一件事是，如果您的系统对sub声明的依赖远不止认证和授权，那么您可能需要进行一些调整.例如，我已经看到执行动作A的系统需要知道它是针对用户X和Y的，但是该动作的有效负载仅接收到用户Y并假定用户X是当前经过身份验证的主体.当一切都是同步的时，这很好用，但是仅通过切换有效负载来指定两个用户，就意味着该操作可以由系统认证的主体异步完成.
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屋！
