Пользовательское требование аутентификации Spring Security 3 .... нужна помощь!

Question

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

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

есть подсказка, пожалуйста?

Answer 1

Похоже, у вас есть две разные роли, ROLE_USER и ROLE_NEW_USER.Хитрость заключается в настройке перехватчика, чтобы указать, какие роли вы хотите.Работа перехватчика состоит в том, чтобы определить ресурсы, которые вы хотите защитить, и какие роли необходимы для доступа к ним.

Вы не указываете, поэтому предположим, что вы создаете веб-приложение.По умолчанию у вас, вероятно, есть какой-то FilterSecurityInterceptor .Конфигурация может выглядеть следующим образом ...

Это говорит о том, что доступ ко всем URL-адресам защищен и требует ROLE_USER.Если у вашего веб-приложения есть URL-адреса, соответствующие этому варианту использования, вы можете сделать что-то вроде ...

Конечно, если ваше веб-приложение не так удачно структурировано,все становится сложнее.Например, возможно, доступ к /updateConfig?newpassword=foobar разрешен, чтобы пользователь мог изменить свой пароль, но доступ к /updateConfig?username=newname не должен быть разрешен.

В этом случае вам придется разместить перехватчик наболее низкий уровень.Возможно, вы можете использовать MethodSecurityInterceptor для предоставления доступа к вашей службе конфигурации, чтобы у метода setPassword был ROLE_NEW_USER, а у метода setName - ROLE_USER.Просто помните, что MethodSecurityInterceptor является аспектом, поэтому, если у вас есть класс ConfigService с методами setConfig, setPassword и setName, а веб-служба вызывает setConfig, которая вызывает setPassword и setNameтогда это не сработает, поскольку аспекты не применяются к вызовам методов внутри класса.

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

Если вы свернете свой собственный перехватчик, вы захотите взглянуть на класс SecurityContext, который предоставляет вам объект Authentication для текущего потока (например, запрос).

You 'Вам также потребуется изменить реализацию UserService, чтобы она, когда она предоставляет пользователей, устанавливала соответствующую роль (ROLE_USER или ROLE_NEW_USER на основе тега базы данных).

Последнее, но не менее важное, вы захотите выяснитькак ваше приложение справляется с ошибками аутентификации.В примере с веб-сервисом вы можете перенаправить своих пользователей на страницу смены пароля, если они когда-либо не пройдут аутентификацию.Конечно, может быть сложно перенаправить их на страницу смены пароля, если они ROLE_NEW_USER, и на страницу регистрации, если у них нет роли.

Answer 2

Возможно, вы захотите пересмотреть свои требования в свете следующего сценария:

• Администратор создает учетную запись для Фреда с паролем по умолчанию.

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

• Тем временем Джим, который знает (или уже догадался), что у Фреда есть новая учетная запись, входит в систему как Фред, используя пароль по умолчанию, сбрасывает его и теперь может делать вид, что он Фред ... пока Фред не окончательно пытается использовать свою учетную запись и терпит неудачу, потому что он не знает пароль.

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