Управление сеансом между толстым клиентом и сервером?

Question

Мое приложение - это Eclipse Rich Client, и я хотел бы добавить функции аутентификации и авторизации. Мои пользователи и роли хранятся в базе данных, и мое приложение также имеет веб-консоль администратора, которая позволяет мне управлять пользователями и ролями. Я использую Spring security на этой консоли администратора.

Так вот мое требование:

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

Я действительно не могу придумать какой-либо простой способ сделать это. Я знаю, что если бы я использовал Spring Rich Client, он бы хорошо интегрировался с Spring Security на стороне сервера. Но это не вариант для меня на данный момент.

Пожалуйста, поделитесь своими мыслями о том, как добиться этого. Ценю вашу помощь.

Answer 1

Возможно, это поможет вам:

http://prajapatinilesh.wordpress.com/2009/01/14/manually-set-php-session-timeout-php-session/

Обратите особое внимание на это (для форсирования сбора мусора):

ini_set(’session.gc_maxlifetime’,30); 
ini_set(’session.gc_probability’,1); 
ini_set(’session.gc_divisor’,1); 

Существует также другая переменная называется session.cookie_lifetime, которые вы можете иметь также изменить.

IIRC, есть как минимум 2, возможно, больше переменных, которые вы должны установить. Я не помню, насколько я был в жизни, но я помню, что было больше 1.

Answer 2

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

Answer 3

У меня такое же требование, я думаю. В нашем случае:

• пользователь предоставляет имя пользователя и пароль при входе в систему
• проверить это против таблицы USER (пароль не в виде простого текста BTW)
• , если действительно, мы хотим, чтобы сеанс длиться, скажем, 20 минуты; мы не хотим проверять имя пользователя и пароль каждый раз, когда толстый клиент выполняет извлечение данных или данных хранилища (мы это делаем ), и на самом деле это не конец света, но это дополнительный DB op, что не нужно)

В нашем случае у нас есть много привилегий для рассмотрения, а не только логическое «имеет или не имеет доступа». То, что я собираюсь сделать, - создать глобально уникальный токен/ключ сеанса (например, java.util.UUID), который толстый клиент сохраняет в локальном объекте ThickClientSession.

Каждый раз, когда толстый клиент инициирует операцию, например. вызывает getLatestDataFromServer(), этот ключ сеанса передается на сервер.

Сервер приложений (например, веб-приложение Java, работающий под управлением Tomcat) по существу является безстоящим, за исключением записи этого сеансового ключа. Если я запишусь в 10 утра, тогда сервер приложений запишет ключ сеанса как действительный до 10:20. Если я запрашиваю данные в 10:05 утра, срок действия ключа сеанса продолжается до 10:25 утра. Различные уровни привилегий, сопровождающие сеанс, также находятся в состоянии. Это можно сделать с помощью простой карты Map, установленной на UUID.

Как сделать эти звонки: рекомендую Spring HTTP Invoker. Здорово. Вам не нужна полноценная инфраструктура Spring Rich Client, она может быть легко интегрирована в любую технологию Java-клиента; Например, я использую Swing для этого. Это можно объединить с SSL в целях безопасности.

Как бы то ни было, я планирую заняться этим. Надеюсь, это будет полезно!

Answer 4

Недавно я разработал подобное приложение, используя Challenge-Response-authentication. В основном у вас есть три метода в вашем веб-сервиса или на сервере

getChallenge(username) : challenge 
getSession(username, response) : key 
getData(username, action?) : data 

getChallenge возвращает значение (случайное значение, или временную метку, например), что клиент хэширует с его/ее пароль и отправляет обратно в getSession. Например, сервер хранит имя пользователя и вызов на карте.

В getSession сервер вычисляет один и тот же хэш и сравнивает его с ответом от клиента. Если это правильно, ключ сеанса генерируется, сохраняется и отправляется клиенту, зашифрованному паролем пользователей. Теперь каждый вызов getData может шифровать данные с помощью ключа сеанса, и поскольку клиент уже проверен в getSession, ему/ей не нужно снова «входить в систему».

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