Внедрение пользовательского AuthenticationProvider в Spring Безопасность 2.06

Я использую Spring Security для защиты веб-приложения Struts2. Из-за ограничений проекта я использую Spring Security 2.06.

Моя команда построила пользовательский API управления пользователями, который аутентифицирует пользователя после ввода параметров имени пользователя и пароля и возвращает пользовательский объект, содержащий список ролей и других атрибутов, таких как электронная почта, имя и т.д.

С моей точки зрения, типичный Spring случай использования безопасности использует UserDetailsService по умолчанию для извлечения объекта UserDetails; этот объект будет содержать (помимо прочего) поле пароля, которое будет использоваться каркасом для аутентификации пользователя.

В моем случае я хочу, чтобы наш пользовательский API выполнял аутентификацию, а затем возвращал пользовательский объект UserDetails, содержащий роли и другие атрибуты (электронная почта и т.д.).

После некоторых исследований я понял, что могу сделать это с помощью пользовательской реализации AuthenticationProvider. У меня также есть пользовательские реализации UserDetailsService и UserDetails.

Моя проблема в том, что я действительно не понимаю, что я должен возвращать в CustomAuthenticationProvider. Я использую свой пользовательский объект UserDetailsService здесь? Это даже необходимо? Извините, я действительно смущен.

Надеюсь, это имеет смысл. Любая помощь или указатели будут оценены!

У меня есть пользовательский объект аутентификации, реализующий интерфейс аутентификации:

Он работает, если я возвращаю объект UsernamePasswordAuthenticationToken, но если я попытаюсь вернуть CustomAuthentication, я получаю следующую ошибку:

Это похоже на то, что ожидается не только любой объект аутентификации, но и конкретная реализация его - UsernamePasswordAuthenticationToken. Это заставляет меня думать, что я могу пропустить другой пользовательский компонент. Может быть, фильтр?

Ответы

Ответ 1

Если вы реализуете свой собственный AuthenticationProvider, вам не нужно реализовывать UserDetailsService, если вы этого не хотите. UserDetailsService просто предоставляет стандартную DAO для загрузки пользовательской информации, а некоторые другие классы в рамках этой платформы реализованы для ее использования.

Обычно для аутентификации с использованием имени пользователя и пароля вы создаете DaoAuthenticationProvider и вводите это с помощью UserDetailsService. Это может быть вашим лучшим подходом. Если вы внедряете своего собственного провайдера, вы берете на себя ответственность за то, чтобы пользователь предоставил правильный пароль и так далее. Однако в некоторых случаях это более простой подход.

Чтобы ответить на ваше "что должно произойти здесь?" комментарий в вашем коде, это было бы что-то вроде

@Override
public Authentication authenticate(Authentication authentication) throws AuthenticationException {
  UsernamePasswordAuthenticationToken auth = (UsernamePasswordAuthenticationToken) authentication;
  String username = String.valueOf(auth.getPrincipal());
  String password = String.valueOf(auth.getCredentials());

  logger.info("username:" + username);
  logger.info("password:" + password); // Don't log passwords in real app

  // 1. Use the username to load the data for the user, including authorities and password.
  YourUser user = ....

  // 2. Check the passwords match (should use a hashed password here).
  if (!user.getPassword().equals(password)) {
    throw new BadCredentialsException("Bad Credentials");
  }

  // 3. Preferably clear the password in the user object before storing in authentication object
  user.clearPassword();

  // 4. Return an authenticated token, containing user data and authorities  

  return new UsernamePasswordAuthenticationToken(user, null, user.getAuthorities()) ;
}

Пользовательский объект затем будет доступен с помощью

Authentication.getPrincipal()

и вы можете получить доступ к дополнительным свойствам (электронной почте и т.д.), переведя его в пользовательскую реализацию пользователя.

Как вы загружаете пользовательские данные, зависит от вас. Все Spring Безопасность заботится здесь о AuthenticationProvider интерфейсе.

Вы также должны хранить хешированные пароли и проверять предоставленный пароль с использованием того же алгоритма, а не простой проверки равенства.

Ответ 2

спасибо за публикацию этого Люка!

Сохранял меня от большего количества повреждений головного мозга.

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

Моя настройка:

Grails 2.0.4
Groovy 1.8
spring -security-core 1.2.7.3
spring -security-ui 0.2
hibernate 2.0.4

При использовании сильно оцененного упрощенного/элегантного подхода, который предлагает Люк, НЕ реализуя пользовательский объект UserDetails (или UserDetailsService) - и - используя свой собственный объект домен, который не распространяется ни на что особенное, вы должны сделайте дополнительный шаг, если вы используете пользовательские теги "sec" из spring безопасности (на ваших страницах, конечно):

Когда вы создаете базовый, нестандартный UserPasswordAuthenticationToken, вы ДОЛЖНЫ передать ему экземпляр того, что расширяет Principal, опять же, если вы хотите, чтобы ваши теги пользовательских разметок безопасности spring работали. Я сделал что-то вроде этого, чтобы сделать его максимально простым (ссылаясь на мои значения объекта пользовательского домена, где это полезно/подходит):

def principalUser = new org.springframework.security.core.userdetails.User(user.username, user.password, user.enabled, !user.accountExpired, !user.passwordExpired,!user.accountLocked, authorities)
def token = new UsernamePasswordAuthenticationToken(principalUser, presentedPassword, authorities)

Это должно удовлетворять условиям, проверенным в grails.plugins.springsecurity.SecurityTagLib.determineSource(), поэтому вы знаете, что ваши страницы, которые используют <sec:loggedInUserInfo>, будут фактически отображаться:

if (principal.metaClass.respondsTo(principal, 'getDomainClass')) {
            return principal.domainClass
}

В противном случае, если вы создадите экземпляр UsernamePasswordAuthenticationToken с помощью объекта вашего домена пользователя (как показано в его примере в Luke), этот метод lib для метода безопасности (defineSource()) просто сделает это лучше всего и вернет (meta) значение org. codehaus.groovy.grails.commons.DefaultGrailsDomainClass, и вы получите сообщение об ошибке, когда тег будет искать переменную-член имени пользователя:

 Error executing tag <sec:ifLoggedIn>: Error executing tag <sec:loggedInUserInfo>: No such property: username for class: org.codehaus.groovy.grails.commons.DefaultGrailsDomainClass

За исключением повторного внедрения/подклассификации тегов taglib-модулей для