Клиентские сессии
Я хочу, чтобы клиенты нескольких связанных веб-приложений держали свое собственное состояние аутентификации. Это улучшает масштабируемость, потому что никакая репликация сессии между кластерными узлами не необходима. И это делает интеграцию различных технологий сервера как Сервлеты Java и PHP легче.
Мой план следующие:
- Установите и зашифрованный cookie со знаком с именем пользователя и время истечения срока сессии после аутентификации клиента.
- Когда клиент отправляет запрос, сервер дешифрует и проверяет cookie и предоставляет или запрещает доступа в зависимости от значений cookie.
- Истечение сессии будет обновлено посредством сброса cookie.
Все серверы, которые хотят использовать сессию, должны только знать механизм cookie и ключ расшифровки.См. также: Состояние сеанса в клиентском уровне
Этот подход хорошо? Было бы возможно интегрировать его в контейнер сервлета / сервер приложений так, чтобы это было очевидно для приложений? Сервлет должен смочь использовать HttpServletRequest#getRemoteUser (), например. Действительно ли это возможно? Или мне было бы нужно что-то выше контейнерного уровня как безопасность Spring? Есть ли какие-либо существующие библиотеки для клиентского управления сеансами?
5 ответов
Не хорошая идея. Хранение жизненно важных данных, таких как истечение срока сеанса и имя пользователя, полностью на стороне клиента, слишком опасна IMO, зашифровано или нет. Даже если концепция технически безопасна сама по себе (я не могу ответить на это глубину, я не эксперт на шифрование), перерыв может быть облегчен без компромисса вашего сервера, просто приобретая ключ шифрования.
Кто-то, кто получает ключ, может генерировать сеансные файлы cookie на воле, осенсение любого пользователя для любого продолжительности времени, что-то классическая концепция сеанса предназначена для предотвращения.
Для этой проблемы есть лучшие и масштабируемые решения. Почему бы не, например, настроить центральный экземпляр проверки сеанса, что все соответствующие серверы и услуги могут опросить? Посмотрите на Интернет, я на 100% уверен, что есть готовые решения, касающиеся ваших потребностей.
Вы можете избежать дублирования данных в кластерной среде с использованием состояния сервера - сервер, который хорошо известен всеми узлами в кластерах и поддерживает данные сеанса для всех пользователи. Каждый раз, когда пользователь выполняет запрос, он отправляет файл cookie с идентификатором сеанса на сервер приложений; Этот должен получить сеанс с государственного сервера. Это возможно для развития ASP.NET, но я не уверен, насколько легко Java поддерживает этот подход.
Достаточно создать вашу регистрационную форму из вашей модели пользователя. Если адрес электронной почты определен, чтобы быть уникальным там, форма выводится ошибка при отправке для дубликатов адресов.
Посмотрите здесь для деталей.
Как доминика указывает, вы не сможете это сделать со встроенным профилем пользователя. Вам придется продлить его, создавая свой собственный профиль пользователя, как описано здесь и сделать его содержать уникальный адрес электронной почты.
-121--1714739-Это улучшает масштабируемость, потому что не требуется репликация сеанса между узлами кластеров.
Во-первых, использование сеанса HTTP на самом деле не позволяет вам от масштабирования, даже при использовании репликации состояния HTTP-сеанса (некоторые механизмы умнее других, например, для репликации Meblogic т имеют большой накладной расходы). Во-вторых, вам действительно это нужно? Большинство приложений (большинство) не нуждаются в репликации сеанса. В-третьих, я понимаю правильно: планируете ли вы вообще не использовать сеанс HTTP?
(...) Установите подписанный и зашифрованный файл cookie с именем пользователя и время истечения сеанса после аутентификации клиента.
Не делай этого! Не храните имя пользователя и другие разумные данные, используемые сервером в cookie, это очень плохое представление! На самом деле вам нужно признать, что это просто вопрос времени, прежде чем кто-то выясняет, как ваша система работает и разбивает ее (особенно если ваш cookie кандидата для кандидата атак). SOR, действительно, вы должны хранить данные на сеансе на стороне сервера и только идентификатор в файле cookie, как и на самом деле работает. Это гораздо безопаснее.
Это подход ОК?
Нет. И вам не нужно это для совместимости односторонних (если это то, что вы пытаетесь построить). Просто используйте централизованное решение аутентификации, такое как CAS Jasig , в котором есть библиотеки для различных технологий.
Это на самом деле не реализовано сеансы. Сам cookie не нужно носить какие-либо данные самого сеанса, это просто ссылка на него.
Что удерживает печенье, обычно является идентификатор сеанса , который затем связан с данными на сервере.
Если у вас нет центрального сервера сеанса данных для других серверов для доступа, я предлагаю получить один :).
Как сказал Пекка, это плохая идея. Можно перехватить ваш куки-файл с конфиденциальными сессионными данными. Даже при использовании SSL, с помощью fiddler2 можно расшифровать трафик
.