如何在微服务架构中实现基于角色的安全 [英] how to implement role-based security in microservices architecture

问题描述

我有一个带有 4 个微服务、eureka 服务器和一个集中式 API 网关的 spring-boot 应用程序.

I have a spring-boot application with 4 microservices, eureka server and a centralized API gateway.

所有外部流量都通过我的 API 网关到达我的微服务.

All external traffic is coming via my API gateway to my microservices.

我的 API 网关 (Zuul) 正在验证和验证 JWT 令牌.

My API gateway (Zuul) is validating and verifying JWT token.

JWT 令牌由我的一个微服务(用户微服务)在用户登录后生成，令牌包含用户 ID 及其角色/权限.

the JWT token is generated by one of my microservices after user login (the users microservice), the token contain the user Id and his roles/authorities.

现在，我想对网关以外的微服务中存在的方法实施基于角色的安全性.

Now I want to implement role-based security on methods that are present in microservices other than the gateway.

我尝试使用 @PreAuthorize 但它在网关之外不起作用(显然为了使它起作用，我必须在 SecurityContextHolder 中设置一个 Spring Security 身份验证对象code> 在我的微服务中并用权限填充它).

I have tried to use @PreAuthorize but it's not working out of the gateway (obviously in order to make it work I have to set a Spring Security authentication object in the SecurityContextHolder in my microservices and populate it with authorities).

那么是否有任何解决方案可以实现这种安全性?

So is there any solution to achieve this type of security?

在微服务架构中设置安全性的最佳设计是什么?

What is the best design to set up security in microservice architecture?

API 网关级别的身份验证和微服务级别的授权?

Authentication at API gateway level and authorization at microservices level?

在 API 网关级别验证 JWT 后，我是否需要在微服务中使用 spring security 或仅传递角色(将它们附加到请求中)，例如创建我自己的注释并使用 Spring AOP 处理授权?

Do I need to use spring security within the microservices or just pass down the roles (append them to the request) after validating the JWT at API gateway level and for example create my own annotations and use Spring AOP to handle authorization?

推荐答案

在 Spring5 微服务中，您将能够找到一个基础来开发具有您正在寻找的几个必要条件的微服务架构:

In Spring5 microservices you will be able to find a base to develop a microservice architecture with several of the requisites you are looking for:

• 注册服务器使用 Eureka.
• 网关服务器与 Zuul.

• Registry server using Eureka.
• Gateway server with Zuul.

关于安全性，我开发了两种不同的微服务:

Regarding to security, I have developed two different microservices:

• Spring Oauth2 与 Jwt
• Spring Jwt 多应用安全服务工作具有访问和刷新 Jwt 令牌的功能，具有多种自定义功能，例如:定义每个令牌的内容、使用 JWS 或 JWE 等

• Spring Oauth2 with Jwt
• Spring Jwt multi-application security service to work with access and refresh Jwt tokens, with several customizations like: definition of the content of every one, work with JWS or JWE, etc

最重要的是使用 Swagger 进行了详细记录，如您所见 此处，并且所有记录的 API 都可以使用唯一的网关 URL 访问.

Most important ones are well documented using Swagger, as you can see here, and all documented APIs are accessible using an unique gateway Url.

为每个微服务的所有类开发了Junit 测试.

For all classes of every microservice, Junit tests were developed.

此时，我做出了几个决定:

At this point, I took several decisions:

1.网关不是验证安全的微服务.

1. Is not the gateway the microservice that verifies the security.

因为使用网关作为防火墙"是一种不太灵活的方法.我想决定哪些微服务需要安全性，每个人都应该在内部管理角色可以访问每个端点.总之，每个微服务都必须使用授权/身份验证，但不需要知道该功能是如何完成的.

Because use the gateway as "firewall" is a less flexible approach. I wanted to decide which microservices need security and every one should manage internally the roles can access to every endpoint. In summary, every microservice has to work with the authorization/authentication but it don't need to know how that functionality is done.

2.特定的微服务来处理安全

2. Specific microservice to deal with the security

正如我告诉你的，我开发了 2 个不同的，因为我想玩"有不同的选择/方法.最重要的优势是封装，如果明天"我决定通过任何其他选项更改 Jwt，我只需要修改那些，使用它们的微服务将保持相同的代码(我将很快向您解释集成是如何完成的)

As I told you, I developed 2 different ones, because I wanted to "play" with different options/approaches. The most important advantage is the encapsulation, if "tomorrow" I decide to change Jwt by any other option, I will only need to modify those ones, the microservices that use them will keep the same code (I will explain you soon how the integration was done)

我将解释安全功能是如何集成的:

I will explain how the security functionality was integrated between:

• Pizza service 作为架构的一部分开发的简单微服务.
• Spring Jwt

• Pizza service easy microservice developed as part of the architecture.
• Spring Jwt

1.每个管理用户和角色的应用程序都会在安全微服务中包含一个类似于 下一个，定义它的models，repositories获取需要的信息，等

1. Every application that manages user and roles, will include in the security microservice a folder similar to the next one, to define its models, repositories to get the required information, etc

2. 定义了安全微服务的全局端点 此处.如您所见，它们基本上与 2 个 Dtos 一起工作:

2. Global endpoints of the security microservice are defined here. As you can see, they work basically with 2 Dtos:

• AuthenticationInformationDto
• UsernameAuthoritiesDto

主要优点是，只有安全微服务知道有关该功能如何完成的详细信息，其他使用它的微服务将收到带有所需信息的众所周知的 Dtos.

The main advantage, only the security microservice knows the details about how that functionality was done, the other ones that use it will receive a well known Dtos with the required information.

3.在pizza-service中，安全集成主要定义在接下来的3个类中:

3. In pizza-service, the security integration is mainly defined in the next 3 classes:

• SecurityContextRepository 从标头中获取授权令牌并将其发送到 SecurityManager.
• SecurityManager 使用提供的授权令牌"调用 security-jwt-service(它不知道它是 Jwt 还是其他任何东西)并接收一个众所周知的 UsernameAuthoritiesDto(将其转换为 Spring 类 UsernamePasswordAuthenticationToken 的对象)
• WebSecurityConfiguration 全局安全配置.

• SecurityContextRepository to get authorization token from the header and send it to the SecurityManager.
• SecurityManager call to security-jwt-service with the provided "authorization token" (it doesn't know if it is Jwt or any other thing) and receives a well know UsernameAuthoritiesDto (transforming it into an object of the Spring class UsernamePasswordAuthenticationToken)
• WebSecurityConfiguration global security configuration.

现在您可以在端点中包含所需的基于角色的安全性:

Now you can include in your endpoints the required role based security:

• 控制器示例
• 自定义预授权注释

1. pizza-service 是使用 Webflux 开发的，您可以在 order-service 中看到基于 MVC 微服务的等效集成 这里(在这种情况下我使用其他安全服务"，但很容易适应).

1. pizza-service was developed using Webflux, you can see an equivalent integration based on a MVC microservice one in order-service here (in this case I used the "other security service" but is easy to adapt it).

为了提高安全性并遵循Oauth 方法"，对 security-jwt-service 的请求也需要包含基本身份验证.正如您在 SecurityManager 类中看到的:

To improve the security and follow the "Oauth approach", the requests to security-jwt-service need to include the Basic authentication too. As you can see in SecurityManager class:

private String buildAuthorizationHeader(String username, String password) {
  String auth = username + ":" + password;
  byte[] encodedAuth = Base64.getEncoder().encode(auth.getBytes());
  return "Basic " + new String(encodedAuth);
}

数据库中存储该信息的表与用于管理每个应用程序的安全配置的表相同:security.jwt_client_details

The table in database to store that information is the same one used to manage the security configuration of every application: security.jwt_client_details

这篇关于如何在微服务架构中实现基于角色的安全的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！