Security, Cloud с JWT и WebFlux

Spring Security — довольно крутая штука, на тему которой много гайдов, статей на различных платформах. Но проблема в том, что множество этих видео ограничивается монолитной архитектурой. В этой статье я хочу рассказать о своем личном опыте применения ее для микросервисов. Конечно, это не статья уровня Тагира Валеева. Это исключительно личный опыт, которым хотелось бы поделиться, и может быть, кому то он окажется полезным.

В данной статье будет рассмотрено следующее:

• Механизм регистрации и выдачи JWT токенов пользователям (кратко)

• Механизм авторизации (кратко)

• Security приложения на основании ролей пользователей

Применяемые технологии:

• Spring Boot

• Spring Cloud

• Spring Security

• JWT

• WebFlux

Механика запросов, думаю, многим понятна. Если нет, картинка ниже вкратце все объяснит.

Приходит запрос от пользователя. Он перенаправляется на порт развернутого Gateway, подставляется имя микросервиса, и далее идут обычный end-поинты указанного микросервиса. К примеру: localhost:8888/microserviceName/users.

Переходим к самому интересному!

Предлагаю немного пробежаться по микросервису регистрации, хранения пользователей в базе и выдачи JWT токенов. Предположим, что есть некая Person entity, в которой содержатся Id, username, password, role.

Метод создания пользователя из UserService:

public AuthResponse createPerson(PersonDto dto) {         Person personEntity = mapper.dtoToPerson(dto);         personEntity.setRole(Role.USER);         personEntity.setPassword(BCrypt.hashpw(dto.getPassword(), BCrypt.gensalt()));          repository.save(personEntity);         return getAuthResponse(personEntity);     }  private AuthResponse getAuthResponse(Person personEntity) {         String accessToken = jwt.generate(personEntity, accessType);         String refreshToken = jwt.generate(personEntity, refreshType);         return new AuthResponse(accessToken, refreshToken, personEntity.getMRID());     }

Обратим внимание, что в строке №4 мы хэшим пароль и храним его в БД в зашифрованном виде. На тему генерации JWT токенов на просторах интернета множество полезных статей и видео. Данная же статья в большинстве своем посвящена Security нашего приложения.

Теперь перейдем к самому интересному. Api Gateway! На нем остановимся поподробнее.

Требуемые зависимости:

    implementation 'org.springframework.boot:spring-boot-starter-security:2.6.8'     implementation 'org.springframework.boot:spring-boot-starter-webflux:2.6.8'     implementation 'org.springframework:spring-webmvc:5.3.22'      implementation 'io.jsonwebtoken:jjwt-api:0.11.2'     runtimeOnly 'io.jsonwebtoken:jjwt-impl:0.11.5'     runtimeOnly 'io.jsonwebtoken:jjwt-jackson:0.11.1'

Security config:

@EnableWebFluxSecurity @RequiredArgsConstructor public class SecurityConfig {      private final AuthenticationManager authenticationManager;     private final SecurityContextRepository securityContextRepository;      @Bean     public SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) {         http                 .csrf()                 .disable()                 .authenticationManager(authenticationManager)                 .securityContextRepository(securityContextRepository)                 .authorizeExchange()                 .pathMatchers("/microservice1/users").permitAll()                 .pathMatchers("/microservice2/emails").authenticated()                 .pathMatchers("/microservice3/persons").hasAuthority("ADMIN")                 .anyExchange()                 .permitAll()                 .and()                 .httpBasic()                 .disable()                 .formLogin()                 .disable();         return http.build();     } }

Заметьте, мы уже используем не@EnableWebSecurity,а @EnableWebFluxSecurity. Данная аннотация необходима, она позволяет нам реализовать Security в Gateway, реактивно бегая по микросервисам.

Как мы знаем, наследование WebSecurityConfigurerAdapter — deprecated. Поэтому реализуем SecurityWebFilterChain и опишем в нем требуемый функционал.

В 5,6 строках есть две важные штуки, а именно: authenticationManager, securityContextRepository.

Для начала рассмотрим SecurityContextRepository:

@Component @RequiredArgsConstructor public class SecurityContextRepository implements ServerSecurityContextRepository {      private final AuthenticationManager authenticationManager;      @Override     public Mono<Void> save(ServerWebExchange swe, SecurityContext sc) {         throw new UnsupportedOperationException("Not supported yet.");     }      @Override     public Mono<SecurityContext> load(ServerWebExchange swe) {         Mono<String> stringMono = Mono.justOrEmpty(swe.getRequest().getHeaders().getFirst(HttpHeaders.AUTHORIZATION));         return stringMono.flatMap(this::getSecurityContext);     }      private Mono<? extends SecurityContext> getSecurityContext(String token) {         Authentication auth = new UsernamePasswordAuthenticationToken(token, token);         return authenticationManager.authenticate(auth).map(SecurityContextImpl::new);     } }

Если вкратце ответить, что здесь происходит, то мы достаем из запроса Authorizarion header и отправляем его в метод authenticate из AuthenticationManager.

А вот и AuthenticationManager:

@Lazy @Component @RequiredArgsConstructor public class AuthenticationManager implements ReactiveAuthenticationManager {      private final Builder webClient;      @Override     public Mono<Authentication> authenticate(Authentication authentication) {         String jwtToken = authentication.getCredentials().toString();         return tokenValidate(jwtToken)                 .bodyToMono(UserAuthorities.class)                 .map(this::getAuthorities);     }      private UsernamePasswordAuthenticationToken getAuthorities(UserAuthorities userAuthorities) {         return new UsernamePasswordAuthenticationToken(                 userAuthorities.getUsername(), null,                 userAuthorities.getAuthorities().stream()                         .map(SimpleGrantedAuthority::new)                         .collect(Collectors.toList()));     }      private ResponseSpec tokenValidate(String token) {         return webClient.build()                 .get()                 .uri(uriBuilder -> uriBuilder.host("registration").path("/token/auth").queryParam("token", token).build())                 .retrieve()                 .onStatus(HttpStatus.FORBIDDEN::equals, response -> Mono.error(new IllegalStateException("Token is not valid")));     } }

В методе tokenValidate мы отправляемся в микросервис registration, в endpoint token/auth. В нем должен быть реализован функционал проверки JWT токена. В нем вы должны брать все claims из JWT токена и записывать в DTO. Выглядит это, примерно, так:

public UserAuthorizationInfo getUserInfoFromToken(String token) {         // здесь должна быть валидация вашего токена          Claims allClaimsFromToken = jwt.getAllClaimsFromToken(token);         UserAuthorizationInfo userInfo = new UserAuthorizationInfo();          userInfo.setPersonId(allClaimsFromToken.get("id").toString());         userInfo.setUsername(allClaimsFromToken.getSubject());          List<String> authorities = new ArrayList<>();         authorities.add(allClaimsFromToken.get(ROLES).toString());         userInfo.setAuthorities(authorities);         return userInfo;     }

Далее мы получаем UserAuthorities, содержащую username и Collection<String> authorities. И по приходу запроса из header-а авторизации достаются username и роль. Теперь мы можем просто указывать, какие endpoint-ы кому доступны в Security Config из Api Gateway и все будет прекрасно работать, и кстати, довольно быстро, реактивщина ведь:)