Spring Security/Ключевые сервисы Spring Security: различия между версиями

<code>PasswordEncoder</code> и <code>SaltSource</code> являются необязательными. <code>PasswordEncoder</code> обеспечивает кодирование и декодирование паролей, представленных в объекте <code>UserDetails</code>, который возвращается настроенным <code>UserDetailsService</code>. <code>SaltSource</code> позволяет "добавлять соль" в пароли, что повышает безопасность паролей в аутентификационном репозитории. Ниже это будет обсуждатсяобсуждаться более подробно.

ВозращаемыйВозвращаемый <code>UserDetails</code> представляет собой интерфейс, который предоставляет геттеры, которые гарантируют not-<code>null</code> результаты аутентификационной информации, такие как имя пользователя, пароль, предоставленные полномочия и является ли учетная запись пользователя заблокированной или нет. Большинство провайдеров аутентификации будет использовать <code>UserDetailsService</code>, даже если имя пользователя и пароль по факту не используются для принятия решения об аутентификации. Они могут использовать объект <code>UserDetails</code> просто для получения информации о <code>GrantedAuthority</code>, потому что некоторые другие системы (например, LDAP и X.509 или CAS и т.д.) берут на себя ответственность за фактическое подтверждение полномочий.

Хэширования паролей не уникальное свойство Spring Security, но явлетсяявляется распространенным источником путаницы для пользователей, которые не знакомы с данной концепцией. Хэш- (или дайджест) алгоритм представляет собой одностороннюю функцию, которая производит некоторые выходные данные фиксированной длинны (хеш) из входных данных произвольной длинны, таких например, как пароль. MD5 хэш строки "password" (в шестнадцатеричной системе) выглядит следующим образом:

Когда аутентификационному провайдеру (такому как <code>DaoAuthenticationProvider</code>) нужно сверить пароль, присланный в аутентификационном запросе со значением, которое известно для данного пользователя и пароль хранится в закодированном виде, то тогда присланное значение должно быть закодировано с помощью точно такого же алгоритма. Совместимость алгоритмов это полностью ваша зона ответственности. Spring Security не может контролировать хранимые значения. Если вы добавили хеширование паролей в конфигурацию аутентификации Spring Security, а в базе данных пароли хранятся в виде обычного не шифрованного текста, то в это случае аутентификация не произойдет ни при каких обстоятельствах. Например, даже если вы знаете что в базе данных используется MD5 кодирование и ваше приложение сконфигурировано так, чтобы использовать <code>Md5PasswordEncoder</code> из состава Spring Security, то все равно есть возможность получить ошибку. В базе данных кодированные пароли могут храниться в виде <tt>Base64</tt> , а кодировщик Spring Security например будет использовать строки с шестнадцатеричными значениями (по умолчанию) [5]. Или в базе данных сведения будут хнаритьсяхраниться в верхнем регистре, а результат работы кодировщика будет в нижнем регистре. Обязательно напишите тест, который будет сверять результат работы настроенного кодировщика (на основе известного пароля и «соли») с данными хранящимися в базе данных, до того как двигаться дальше и применять механизм аутентификации в вашем приложении. Для получения дополнительной информации, как по умолчанию происходит слияния соли и пароля, см. Javadoc для <code>BasePasswordEncoder</code>. Если вы захотите создавать закодированные пароли непосредственно в Java коде и уже их сохранять в базе данных, то вы можете использовать метод <code>encodePassword</code> класса <code>PasswordEncoder</code>.