Смена пароля Требуется ответ от службы токенов RESTful

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

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

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

Вопросы

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

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

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


authentication rest security restful-authentication
person SonOfPirate    schedule 31.01.2012    source источник
comment
Почему бы вам просто не сделать так, чтобы конечная точка смены пароля принимала все, что ей нужно для выполнения задания (предположительно, идентификатор пользователя, старый пароль и новый пароль) в качестве параметров и не нуждалась в сеансе?   -  person Celada    schedule 02.02.2012
comment
Ты заставил меня почесать голову. Во-первых, как я уже сказал в посте, у меня нет сеанса, поэтому я не уверен, к чему вы там клоните. Во-вторых, конечная точка смены пароля ДЕЙСТВИТЕЛЬНО принимает все, что ей нужно. Наконец, и это самое главное, вопросы не имеют ничего общего со сменой пароля. Я спрашиваю об аутентификации пользователя, которому требуется смена пароля, и о том, как сообщить об этом состоянии клиенту таким образом, чтобы он соответствовал безопасности на основе токенов.   -  person SonOfPirate    schedule 02.02.2012
comment
извините за термин сеанс. Я имел в виду то, что вы назвали пользовательским токеном безопасности. Все, что я хотел сказать, это то, что клиент не получит ни одного из них, пока он не изменит свой пароль (кажется, отвечает на вопросы Q # 1 и Q # 3), и ему не нужно это, чтобы изменить свой пароль, так где проблема? Что касается того, как сообщить клиенту, что ему нужно изменить свой пароль (Q # 2), это все, что вы хотите сделать (специальный статус HTTP, что-то в теле JSON, пользовательский заголовок и т. д.).   -  person Celada    schedule 02.02.2012
comment
Хорошо, это имеет больше смысла. Причина, по которой я рассматривал ответ с токеном, заключается в том, что клиент может передать личность текущего пользователя с запросом на смену пароля, чтобы пользователь мог быть авторизован. Например, только пользователь или его руководитель могут изменить свой пароль.   -  person SonOfPirate    schedule 02.02.2012
comment
Я думаю, что изменение собственного пароля и изменение чьего-либо пароля супервизором — это две концептуально разные вещи, и их следует обрабатывать двумя разными URL-адресами. Первый не хочет, чтобы вы уже были аутентифицированы, и ему нужны как старые, так и новые пароли. Последний требует, чтобы вы уже были аутентифицированы (как супервизор или суперпользователь) и не принимает старый пароль. Первый не ожидает увидеть пользовательский токен безопасности. Последний должен это увидеть и подтвердить.   -  person Celada    schedule 03.02.2012
comment
Просто хотел отметить, что я не могу пометить ответ на вопрос, когда есть только комментарии.   -  person SonOfPirate    schedule 10.02.2012

Ответы (1)


arrow_upward
1
arrow_downward

Итак, что я в итоге сделал (конечно, не решение для всех и всех), так это то, что моя конечная точка Authenticate возвращает пронумерованное значение AuthenticationResultCode в ответе вместо простого логического значения «пройдено/не пройдено». Возможные значения перечисления включают:

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

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

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

person SonOfPirate    schedule 13.04.2012