Пытаюсь освоить и прикрутить что-нибудь из J2EE.

Мое клиентское java приложение ( WebStart ) загружает с сервера данные по мере необходимости GET запросом (http).  Фактически , сервер в этом случае выступает как сервис. Только возвращаемые данные не в хмл формате, не SOAP. Ну, наверное похоже на REST - cервис, хотя вообще-то наоборот. Не принципиально. 

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

Разобрался. Клиентское приложение после предьявления пары имя-пароль получает в ответ токен - jsessionid. И все последующие запросы к сервису должны посылать эту куку в хедере.

Теперь вопрос. Предположим, что добрый пользователь залогинившись извлечет свое значение jsessionid ( это обычный текст) и раздаст своим соратникам. Соратники получат доступ к ресурсам. 

Как этому воспрепятствовать?   Весь обмен осуществлять на HTTPS ? Не хотелось бы, потому что большие обьемы данных.

Это сообщение отредактировал(а) COVD - 24.1.2009, 20:39

1. А в чем угроза такого поведения?
2. Почему бы не привязать к session ID еще и IP?

Это сообщение отредактировал(а) Platon - 24.1.2009, 20:43

Тоже самое, если добрый пользователь даст соратникам свой логин и пароль. 



Сканировать сетчатку глаза, брать отпечатки пальцев. Ну или не пускать несколько клиентов с одними и теми же идентификационными данными и разными IP.

Если пользователь передаёт свою аутентификационную информацию третьим лицам, то никакие технические средства не помогут. jsessionid тут не причем. С таким же успехом он может передать логин/пароль или сертификат для соединения по SSL.

Platon


Угроза в том, что доступ к информации оплатит только один.   



IP клиента иногда меняется его провайдером и может пострадать вполне законный клиент.


powerOn



... одновременно 

Это правильный подход, т.е. только один пользователь с парой имя-пароль. Этот подход естественным образом реализуется, когда клиенту позволено иметь только одно постоянное соединение с сервером для всех своих нужд. Но это не совсем "сервис ориентед". 

ivg




В общем, коллеги, вы укрепили мои сомнения, что Kerberos мне товарищ. 


Это сообщение отредактировал(а) COVD - 24.1.2009, 23:01

в точку   
В этом случае спасет. только защищенный протокол   

Правильно подметили, можно раздать логин/пароль.

А от себя скажу: 
Вы наверно неправильно поняли меня.
Привязать к сессии IP пользователя.
1. Если еще 1 пользователь подключается с той же sessionId, но с другого IP, то блокируем
2. Если еще 1 пользователь подключается с логином/паролем уже авторизованного пользователя, но с другого IP - блокируем.

Это сообщение отредактировал(а) Platon - 25.1.2009, 15:02

Покупается одна лицензия на бригаду. Или публикуется jsessionid .




Первое, что мы стали делать, это записывать в базу ip клиентов. Но потом обнаружилось, что в течении сессии (а это несколько часов) у пользователя может поменяться ip (а sessionId сохраняется, компьютер не перезапускался).

Компьютер отправляет два запроса GET с интервалом времени. Каждый раз создается новое соединение с сервером. Сервер видит разные адреса соединений.   

Если это невозможно, т.е. мы просто ошиблись, то анализ ip решит все проблемы.

Сервер видит разные адреса в случае если у провайдера клиента возник сбой и при восстановлении соединения с интернетом провайдер выделяет динамический IP. Согласитесь что это достаточно редкий случай?

Урежьте время истечения сессии и сделайте автоматическую авторизацию при просроченной сессии.

Добавлено через 2 минуты и 26 секунд
Мой провайдер, кстати, выделил мне статический IP.

Ну, наверное, редкий. 365 клиентов, у каждого один раз в год случается какая-нибудь фигня, а на сервере атмосфера, что каждый день проблемы.  А бывает, что каждый день у группы товарищей из одной конторы в разгар рабочего дня приблизительно в одно время что-то происходит.


Мне не нравится идея привязки доступа в систему к IP. Но, наверное, тут можно поколдовать. А хотелось сразу готовое индустриальное решение на профессиональном уровне от J2EE. 

Это сообщение отредактировал(а) COVD - 25.1.2009, 18:32

Смарт-карты, usb-ключи и т. п., короче что-то, что трудно скопировать, в отличии от логина/пароля

Для продукта, распространяемого через интернет (WebStart) , это неудобно.  Шаг назад в некотором смысле. Уж лучше пусть подворовывают.

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

Это сообщение отредактировал(а) COVD - 25.1.2009, 20:24

Подождите, если у вас webstart, то есть приложение на Java, которое может запускаться и без браузера, да даже если с браузером, как по вашему клиент узнает сессионный Cookie? я так понимаю в браузере его не будет (или аутентификация на веб-странице? а как потом этот Cookie передаёте в приложение?), у себя в приложении вы его не показываете, так ведь? Что вы используете? Apache HttpClient? Даже если какой нить кул-хацкер просмотрит сетевой трафик, как он эту куку воткнёт потом? Этож надо фильтр какой-то мастерить или ваш код разбирать и переделывать. Но даже и в этом случае можно просто этот Cookie периодически менять или вообще от запроса к запросу. Ну а вариант с логином/паролем - отпинывать аутентификацию если такой пользователь уже залогинен. Остаётся когда "соратники" будут поочерёдно работать. Ну тут просматривать логи с IP-шниками клиентов, и злостных нарушителей лишать доступа, о чем явно предупредить в лицензионном соглашении или где то там.

ivg.     Вы столько предположений сделали. И сами на них же ответили. Причем, правильно.    Кстати, мы довольствуемся HttpURLConnection. Конечно, большинство пользователей не будет возиться с куками. И предложения защиты у вас разумные (только это отнюдь не "просто"). Но, повторюсь, я искал готовое в J2EE. И не потому, что лень программировать, а потому, что пора переходить к стандартным индустриальным решениям. И , наверное, разумно пока использовать form-based , а гурманство отложить до времен, когда это может стать действительно необходимостью. 

Это сообщение отредактировал(а) COVD - 26.1.2009, 06:33