Как можно избежать использования сеансов на стороне сервера для аутентификации в веб-приложении Java?

Question

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

Я хочу развернутьна нескольких системах в конфигурации с балансировкой нагрузки, но я не хочу начинать синхронизацию состояния сеанса в моей инфраструктуре.Существуют ли способы (с использованием спецификационных средств в Java EE или общедоступных библиотек, таких как Spring Security) сохранить состояние аутентификации пользователя без сеансов на стороне сервера, например, путем отправки требуемого состояния обратно клиенту?Если да, есть ли дополнительные риски, о которых мне нужно знать?

---

Обновление - я использую декларативную безопасность в соответствии со спецификациями веб-приложения Java EE и аутентифицируюсь через репозиторий LDAP.

Answer 1

Мне неизвестно о каркасном решении, но работает следующее:

После успешного входа в систему пользователь создает защищенный токен и устанавливает его значение в виде файла cookie. Токен содержит всю необходимую информацию (идентификатор пользователя, время создания и т. Д.) И шифруется с использованием некоторого алгоритма. Таким образом, все узлы в вашем кластере могут прочитать токен, расшифровать его и идентифицировать пользователя. Затем вы создаете ServletFilter, перехватывая все запросы, проверяя токен и устанавливая соответствующие учетные данные пользователя, например, для. ServletRequest.getRemoteUser() с помощью HttpServletRequestWrapper.

Один из способов решения проблемы. Но вы должны позаботиться о том, чтобы самодельная безопасность была хорошо продумана.

Answer 2

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

Что касается того, о чем вы должны знатьимейте в виду, что куки - это что-то простое для доступа, кражи, удаления, отключения и т. д. Токен аутентификации должен быть чем-то надежным и проверяемым (хешируйте комбинацию ip + browser + вращающуюся соль + некоторые другие вещи, которые вы можете проверить).

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

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

Ура,

Answer 3

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