Проверка подлинности RESTful - в результате низкая производительность при высокой нагрузке?

Question

Для веб-службы RESTful мы говорим, что сервер не должен хранить никакого состояния. Теперь для каждого запроса «пользователь» должен проходить проверку подлинности и иметь разрешение на действие, которое он / она желает выполнить.

Теперь каждый запрос будет содержать данные авторизации для этого пользователя. Вот мои заблуждения:

Предполагается, что на главной странице есть поле логина и пароля. Пользователь вводит имя пользователя / пароль, который отправляется обратно на сервер, проверяется пользователем, а затем возвращается «некоторый токен». Теперь этот токен отправляется на сервер при каждом запросе. Вопрос (ы):

• Нужно ли внутренней базе данных иметь отдельную таблицу для хранения этих токены проиндексированы по имени пользователя?
• Если токен хранится в БД, то каждый запрос должен вызывать БД. Разве это не делает сервер БД узким местом во время высокой нагрузки?
• Если токен на самом деле не хранится в БД, что является лучшим «спокойным» местом для его хранения?
• Сеансы, вероятно, НЕ успокаивают, но тогда я не вижу, как растут успокоительные аутентификация / авторизация (w.r.t. вышеупомянутые пункты)?
• Если это НЕ токен, тогда нужно ли отправлять имя пользователя / пароль назад-вперед? (звучит как плохая идея:)

Возможно, я неправильно понимаю концепцию RESTful аутентификации / авторизации. Но действительно ли это так, что для каждого http-запроса «сервис» должен совершить поездку в БД для проверки учетных данных? Есть ли что-то, что может ускорить процесс и при этом придерживаться принципов отдыха? Я мог бы подумать о наличии кеша, в котором хранятся детали, и в случае перезапуска сервера он просто совершает поездку в БД. Это всего лишь выигрыш в производительности, который может усложнить систему (возможно, того стоит, не знаю). Это единственное решение?

Итак, с теоретической / концептуальной точки зрения REST (необязательная реализация), как решается эта проблема (если она вообще существует)? Как вы в своем профессиональном опыте справились с этой проблемой и насколько уместным был подход?

Мы работаем над веб-сервисом Restlet + J2EE + MySQL Restful, и у меня всплыл этот вопрос, но нет удовлетворительных ответов (Google, Stackoverflow и т. Д.). Мне известны базовая и дайджест-авторизация HTTP, но я не знаком с внутренностями хранения / извлечения согласно приведенному выше объяснению.

Answer 1

Дух ОТДЫХА - безгражданство.Это не означает, что состояние клиента не может быть сохранено службой, но на практике это означает, что состояние клиента , хранимое в памяти сервером, как правило, плохо.

Вместо того, чтобы хранить аутентификацию data в памяти или обращаться к БД для проверки каждый раз, вы можете сохранить функцию в памяти (т. Е. Код) который используется для шифрования / дешифрования информации пользователя.Это метод, который также предлагается:

Что я должен хранить в файлах cookie для реализации «Запомнить меня» при входе пользователя в систему

Так, например, что выможет сделать следующее:

1. Когда клиент впервые связывается со службой, у него нет cookie.
2. Вы выпускаете cookie, который содержит информацию о пользователе, и «подписываете» его, используя вашу функцию (что могут делать все серверы, на которых работает ваш код)
3. Когда клиент снова обращается к службе, вы проверяетеесли у него есть печенье;если нет, повторите (2).
4. Однако, если у него есть файл cookie, вы пытаетесь расшифровать (снова, используя единственную функцию, которая реплицируется в вашей инфраструктуре) и убедитесь, что вы можете развернуть и переварить эту информацию идентификатора пользователя.
5. Это проверяет пользователя и дает вам идентификационную информацию, и все это, не заходя в БД больше раз, чем необходимо.И это RESTful.

Имейте в виду, что эта «функция», которую я описываю, не нова - это стандартный безопасный хеш, но основанный на уникальном закрытом ключе, который используется только вашими коллективными серверами.знать о.И вы можете вращать такой ключ и т. Д. При необходимости.

Answer 2

Вы проверяете учетные данные (например, имя пользователя / пароль) во время входа в систему. Когда пользователь успешно входит в систему, вы отправляете ему cookie-файл, содержащий неосуществимый «идентификатор сессии». Этот идентификатор сеанса становится токеном, который разрешает дальнейший доступ после проверки учетных данных. Серверное приложение проверяет токен, находя его в некоторой структуре данных в памяти. Срок действия токенов истекает через некоторое разумное время, чтобы предотвратить исчерпание памяти. Токены явно удаляются из хранилища в памяти, если пользователь явно выходит из системы (нажал кнопку «выйти из системы»).

Важно использовать https при отправке и получении токена - в противном случае прослушивание токена позволяет хакеру «перехватить сеанс». Другими словами, используйте https для всего рабочего процесса приложения от входа до выхода.

Answer 3

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

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

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

Наконец, нет проблем с отправкой имени пользователя / пароля каждый раз, пока вы делаете это через HTTPS.Никогда, никогда не отправляйте важные аутентификационные данные через HTTP.