Клиентские сессии

Question

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

Мой план следующий:

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Этот подход в порядке?

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

Answer 3

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

Answer 4

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

Answer 5

Это не совсем то, как реализованы сессии. Сам по себе cookie не должен содержать какие-либо данные самого сеанса, это всего лишь ссылка на него.

Файл cookie обычно представляет собой Session ID, который затем связывается с данными на сервере.

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

Answer 6

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