Изменение пароля Обязательный ответ от службы RESTful Token - PullRequest
Новая
       12

Изменение пароля Обязательный ответ от службы RESTful Token

0 голосов
/ 01 февраля 2012

Я пытаюсь определить наилучший способ применения правил истечения срока действия пароля в моем решении.

На стороне сервера предоставляется REST API для операций с настраиваемой активной службой маркеров безопасности (своего рода). Клиентские приложения передают учетные данные пользователя в конечную точку REST, где пользователь проходит проверку подлинности на сервере. Ответ включает в себя пользовательский токен безопасности, представляющий пользователя, который затем передается другим методам API, чтобы можно было разрешить вызов. Сервер не имеет состояния и не поддерживает никаких ссылок на идентификационные данные или информацию о претензиях (т.е. без сессий).

У нас есть правила истечения срока действия пароля, которые применяются сервером. Таким образом, при аутентификации пользователя возможно, что срок его пароля истек. Мне нужно сообщить об этом клиенту, чтобы он мог сделать все необходимое, чтобы пользователь изменил свой пароль. (Существует другая конечная точка REST для изменения пароля на сервере.)

Вопросы

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

  2. Как мне сообщить клиенту, что требуется смена пароля? Я думал о включении этого в качестве утверждения в токен, но это потребовало бы от меня переиздания нового токена после изменения пароля или изменения исходного токена, который не разрешен. Другой моей мыслью был собственный код статуса HTTP, который мне соответствовал бы значению «Требуется изменение пароля».

  3. Ответ на этот вопрос, вероятно, зависит от предыдущих двух, но я не хочу авторизовать пользователя, у которого пароль с истекшим сроком, если токен передается любым другим API (кроме изменения пароля). Какой лучший способ справиться с этим?

1 Ответ

1 голос
/ 13 апреля 2012

Итак, что я в конечном итоге сделал (конечно, не решение be-all-end-all), так это чтобы моя конечная точка Authenticate возвращала перечисленное в AuthenticationResultCode значение в ответе вместо простого логического значения pass / fail. Возможные значения для перечисления:

  • ValidCredentials - пользователь прошел аутентификацию, и AuthenticationToken включен в ответ.
  • InvalidCredentials - пользователь не прошел аутентификацию
  • CredentialsExpired - пользователь прошел проверку подлинности, но срок действия его пароля истек. Мне еще предстоит определить, будет ли AuthToken включен в этот результат.
  • NoCredentials - учетные данные не были предоставлены для запроса

Теперь у клиента есть больше информации о результате, чем значение прохождения / неудачи (которое я действительно никогда не проверял в любом случае), и я могу предпринять соответствующее действие в ответ, например, автоматическое отображение ChangePasswordDialog при получении CredentialsExpired.

Как я уже сказал, все еще выясняю, следует ли мне отправлять токен по истечении срока действия учетных данных, потому что я не хочу иметь возможность авторизовать пользователя, если срок его действия истек, но они уже были аутентифицированы один раз и я не думаю, что имеет смысл повторно аутентифицироваться после смены пароля (в конце концов, я должен пройти аутентификацию, чтобы я мог сменить пароль в первую очередь). Может быть, достаточно простого свойства IsLocked или IsExpired на клиенте ...

...