Spring3 Security - SwitchUserFilter - можем ли мы предоставить зашифрованные пароли при реализации UserDetailsService

Question

Обычно поставщик аутентификации тега authentication-manager связан со свойством user-service-ref , которое указывает на компонент, реализующий UserDetailsService , но в моем приложении было использовано его свойство ref , которое указывает на bean-компонент, реализующий AuthenticationProvider . Этот компонент кодирует пароль, предоставленный пользователем, и сравнивает его с закодированным паролем в базе данных. У меня есть следующая конфигурация в spring-security.xml

<beans:bean id="myAuthenticationProvider" class="com.mysecurity.server.security.MyAuthenticationProvider" />

<authentication-manager alias="authenticationManager">
    <authentication-provider ref="eeAuthenticationProvider" />
</authentication-manager>

Теперь, если я использую SwitchUserFilter, ему потребуется ссылка на класс, который реализует UserDetailsService следующим образом:

<beans:bean id="switchUserProcessingFilter" class="org.springframework.security.web.authentication.switchuser.SwitchUserFilter">
    <beans:property name="userDetailsService" ref="userServices" />
    <beans:property name="switchUserUrl" value="/admin/switchUser" />
    <beans:property name="exitUserUrl" value="/exitUser" />
    <beans:property name="targetUrl" value="/" />
</beans:bean>

Проблема в том, что UserDetailsService требует от меня предоставить пароль, который будет совпадать с паролем, предоставленным пользователем, но я не сохраняю исходный пароль в базе данных. Нет возможности предоставить bean-компонент, который реализует интерфейс AuthenticationProvider (как в упомянутом выше свойстве authentication-provider ), или опцию сообщить Spring, что ему необходимо кодировать пароль. перед сравнением с тем, что я предоставляю из базы данных. Есть предложения?

Answer 1

SwitchUserFilter фактически не проверяет пароль. В противном случае это означало бы, что пользователь с правами администратора должен знать пароль для учетной записи, на которую он переключается, что обычно не имеет место. Лучшая аналогия - использование su в Unix.

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