Сервер авторизации Spring OAuth2 с конечными точками привода, защищенными с помощью basi c auth

Question

Сервер авторизации Spring Spring OAuth2. Это один из моих микросервисов (называется управление пользователями). Он содержит пользователей и пароли в базе данных, а также некоторые другие объекты, связанные с безопасностью. Это означает, что у меня есть пользовательская реализация UserDetailsService, которая включает загрузку пользователей для операций Spring Security. Этот микросервис является сервером авторизации, но он также является сервером ресурсов, поскольку существует некоторая постоянство и логины домена c, относящиеся к пользователям, организациям, OrganizationMemberships и т. Д. c ... К большинству моих конечных точек REST обращаются с маркером OAuth2 в заголовке и все работает нормально.

Но я также использую Spring Actuator, к которому обычно обращается сервер Spring Boot Admin. Для этих конечных точек я использую Http basi c auth, поэтому у меня есть несколько пользовательских WebSecurityConfigurerAdapter для / actator / ** конечных точек. Во всех микросервисах у меня есть пользователь для доступа к этим конечным точкам привода, определенный в конфигурации application.yaml, и он работает нормально. Но ... В случае такого управления пользователями с пользовательской реализацией UserDetailsService это не работает.

Проблема заключается в том, что при выполнении basi c auth для вызовов конечной точки привода DaoAuthenticationProvider имеет ссылку на мой пользовательский UserDetailsService, который пытается найти пользователя в моей базе данных, а его там нет. Когда это происходит во всех других микросервисах, тогда есть реализация InMemoryUserDetailsManager UserDetailsService (используется DaoAuthenticationProvider), которая содержит пользователя из application.yaml.

Есть идеи, как решить или подойти к проблеме?

• Создать пользователя для доступа конечных точек привода к базе данных? Мне это не нравится, потому что оно отличается от других моих микросервисов
• Создать делегирующий UserDetailsService, который бы проверял оба хранилища пользователей? Я не уверен, как его настроить, так как InMemoryUserDetailsManager не похож на управляемый бин, поэтому есть какое-то ручное программирование.
• Или есть другой правильный подход? Как это настроить?

Большое спасибо, Лукас

Answer 1

После некоторых исследований я нашел решение, которое выглядит вполне нормально. Я создал специальную конфигурацию для конечных точек привода, где я смог установить отдельную реализацию UserDetailsService. Я выбрал InMemoryUserDetailsManager, который используется по умолчанию, когда вы не используете пользовательскую реализацию.

Это означает, что другие экземпляры WebSecurityConfigurerAdapter и реализация AuthorizationServerConfigurerAdapter не влияют на безопасность этих конечных точек привода

@Configuration
@Order(1)
public class CustomWebSecurityConfigurerAdapter extends WebSecurityConfigurerAdapter {

    @Autowired
    private InMemoryUserDetailsManager inMemoryUserDetailsManager;

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.userDetailsService(inMemoryUserDetailsManager)
                .antMatcher("/actuator/**").httpBasic().and()
                .csrf().disable()
                .headers().disable();
    }
}

Мне пришлось вручную создать экземпляр InMemoryUserDetailsManager и ввести значения из конфигурации.

    @Value("${spring.security.user.name}")
    private String systemUserName;

    @Value("${spring.security.user.password}")
    private String systemUserPassword;

    @Bean
    public InMemoryUserDetailsManager inMemoryUserDetailsManager()
    {
        List<UserDetails> userDetailsList = new ArrayList<>();
        userDetailsList.add(User.withUsername(systemUserName).password(systemUserPassword).authorities("USER").build());

        return new InMemoryUserDetailsManager(userDetailsList);
    }