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 и все будет прекрасно работать, и кстати, довольно быстро, реактивщина ведь:)