Сессии на стороне клиента

Question

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

Мой план заключается в следующем:

1. Установить подписано и зашифровано печенье с момента истечения срока действия имени пользователя и сессии после аутентификации клиента.
2. Когда клиент отправляет запрос, сервер расшифровывает и проверяет cookie и предоставляет или запрещает доступ в зависимости от значений cookie.
3. Завершение сеанса будет обновлено путем сброса файла cookie.

Все серверы, которые хотят использовать сеанс, должны знать только механизм cookie и ключ дешифрования. См. Также: Session state in the client tier

Подходит ли этот подход? Можно ли интегрировать его в сервлет-контейнер/сервер приложений, чтобы он был прозрачным для приложений? Сервлет должен иметь возможность использовать HttpServletRequest # getRemoteUser(), например. Это возможно? Или мне нужно что-то выше уровня контейнера, такого как Spring Security? Существуют ли существующие библиотеки для управления сеансами на стороне клиента?

Answer 1

Неплохая идея. Хранение жизненно важных данных, таких как истечение сеанса и имя пользователя целиком на стороне клиента, слишком опасно IMO, зашифровано или нет. Даже если концепция технически безопасна сама по себе (я не могу полностью ответить на этот вопрос, я не эксперт по шифрованию), взломам можно было бы упростить без ущерба для вашего сервера, просто приобретя ключ шифрования.

Кто-то, кто завладеет ключа может генерировать сеансовый куки по желанию, выдает себя любого пользователя для любого отрезка времени, что-то классическое понятие сеанса призвано предотвратить.

Для решения этой проблемы существуют более совершенные и масштабируемые решения. Почему бы не создать, например, экземпляр проверки центрального сеанса, который могли бы опросить все связанные серверы и службы? Осмотритесь в Интернете, я на 100% уверен, что есть готовые решения, отвечающие вашим потребностям.

Answer 2

На самом деле это не так, как выполняются сеансы. Сам файл cookie не должен переносить данные самого сеанса, это просто ссылка на него.

Что такое куки-файл, обычно это Session ID, который затем связан с данными на сервере.

Если у вас нет центрального сервера сеансов передачи данных для доступа к другим серверам, я предлагаю его получить :).

Answer 3

Вы можете избежать дублирования данных в кластерной среде с помощью государственного сервера - сервера, который хорошо известен всем узлам кластеров и поддерживает данные сеанса для всех пользователей. Каждый раз, когда пользователь выполняет запрос, он отправляет файл cookie с идентификатором сеанса на сервер приложений; этот должен получить сеанс с государственного сервера. Это возможно для разработки asp.net, но я не уверен, насколько простой Java поддерживает этот подход.

Answer 4

Это улучшает масштабируемость, поскольку репликация сеанса между узлами кластера не требуется.

Во-первых, с помощью HTTP-сессии на самом деле не мешает вам масштабирования, даже при использовании HTTP состояния сеанса репликации (некоторые механизмы умнее других по пути, например WebLogic-х in-memory replication не имеет большой накладные расходы) , Во-вторых, вам это действительно нужно? Большинство приложений (большинство) не нуждаются в репликации сеанса. В-третьих, я правильно понимаю: планируете ли вы вообще не использовать HTTP-сессию?

(...) Установить подписанный и зашифрованный файл cookie с именем пользователя и временем истечения срока действия сеанса после аутентификации клиента.

Не делайте этого! Не храните имя пользователя и другие разумные данные, используемые сервером в файле cookie, это очень плохая идея! Вы действительно должны признать, что это всего лишь вопрос времени, прежде чем кто-то выяснит, как работает ваша система и разрывает ее (особенно, если ваш файл cookie является кандидатом на атаки crib). Сор, действительно, вы должны хранить данные в сеансе на стороне сервера и только идентификатор в cookie, как будто все работает. Это намного безопаснее.

Подходит ли этот подход?

No. И вам не нужно для совместимой single-sign on (если это то, что вы пытаетесь построить). Просто используйте централизованное решение для проверки подлинности, например CAS Jasig, в котором есть библиотеки для различных технологий.

Answer 5

Как сказал Пекка, это не очень хорошая идея. Можно перехватить ваш файл cookie с конфиденциальными данными сеанса. Даже с SSL, используя fiddler2, можно decrypt трафик

Answer 6

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