Пример Cas и Spring: я не понимаю "setUserDetailsService" - PullRequest
Новая
       41

Пример Cas и Spring: я не понимаю "setUserDetailsService"

0 голосов
/ 11 сентября 2018

В этом примере: https://www.baeldung.com/spring-security-cas-sso

есть этот кусок кода: 

@Bean
public CasAuthenticationProvider casAuthenticationProvider() {

    CasAuthenticationProvider provider = new CasAuthenticationProvider();
    provider.setServiceProperties(serviceProperties());
    provider.setTicketValidator(ticketValidator());
    provider.setUserDetailsService(
      s -> new User("casuser", "Mellon", true, true, true, true,
        AuthorityUtils.createAuthorityList("ROLE_ADMIN")));
    provider.setKey("CAS_PROVIDER_LOCALHOST_9000");
    return provider;
}

Я не понимаю эту часть: 

provider.setUserDetailsService(
      s -> new User("casuser", "Mellon", true, true, true, true,
        AuthorityUtils.createAuthorityList("ROLE_ADMIN")));
  1. что мы должны положить сюда? Я должен создать свой собственный UserDetailsService (если да, то как?)? Я ожидал, что какой-то «сервис подробностей пользователя по умолчанию» ...
  2. как работает этот код? создание пользователя для предоставления UserDetailsService?

1 Ответ

0 голосов
/ 11 сентября 2018

Вот как Spring Spring работает на высоком уровне.

Пользователь пытается аутентифицироваться через некоторый тип пользовательского интерфейса (например, часть CAS). Пользовательский интерфейс будет передавать имя пользователя / пароль в Spring. Spring в конце концов вызовет UserDetailService.loadUserByUsername и передаст ему имя пользователя, а если пользователь существует, UserDetailService вернет ненулевое UserDetails. В случае нулевого UserDetails или ненулевого с другим паролем Spring не пройдет аутентификацию.

CAS - это просто сервер аутентификации, он оставляет открытым способ хранения пользователя. Вы можете использовать LDAP или базу данных. Этот выбор основан на другой реализации UserDetailService. Посмотрите на javadoc еще раз. Он содержит список реализаций по умолчанию, которые вы можете использовать.

См. Часть 5 вашего связанного урока. Он показывает, как вы можете изменить и CAS, и приложение Spring Boot, чтобы использовать базу данных в качестве хранилища пользователя. Ключевым моментом здесь является то, что для того, чтобы серверная часть работала с CAS-сервером против пользователей, хранящихся в базе данных, обе должны быть соответствующим образом настроены для поиска пользователя по базе данных. CAS настраивается через application.properties, а Spring загружается через UserDetailService.

Теперь к вашим вопросам в комментарии:

почему клиент должен беспокоиться о том, как сервер хранит пользователей?

Клиент не должен беспокоиться о UserDetailService. Он используется только серверной службой, которая защищена CAS.

Просто чтобы быть уверенным, что я все понял: если мне просто нужно знать, это пользователь подключен? тогда CAS достаточно, и я никогда не буду использовать UserDetailService. Но если мне нужна информация о пользователе (имя, телефон и т. д.), затем я вызываю UserDetailService, чтобы загрузить его (из db, ldap или чего-либо еще).

Да и нет. Вам не нужно хранить пароль в UserDetails, но вы должны иметь возможность вернуть UserDetails для успешного аутентифицированного пользователя CAS. Смотрите эту часть из вашего связанного урока:

Обратите внимание, что участник базы данных, который использует сервер должно быть таким же, как у клиентских приложений.

...