| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java EE (J2EE) и Spring > Аутентификация J2EE |
| Автор: COVD 24.1.2009, 20:32 |
| Пытаюсь освоить и прикрутить что-нибудь из J2EE. Мое клиентское java приложение ( WebStart ) загружает с сервера данные по мере необходимости GET запросом (http). Фактически , сервер в этом случае выступает как сервис. Только возвращаемые данные не в хмл формате, не SOAP. Ну, наверное похоже на REST - cервис, хотя вообще-то наоборот. Не принципиально. Захотелось добавлять новые сервисы (фактически, сервлеты) как отдельные приложения. Одно приложение - один сервлет, т.е. один сервис. Удобство в автодеплое - добавил\удалил war в Томкат не останавливая остальные. Для этого хорошо бы иметь общую на весь контейнер систему авторизации. Поэтому стал разбираться с form-based авторизацией на Томкате. Разобрался. Клиентское приложение после предьявления пары имя-пароль получает в ответ токен - jsessionid. И все последующие запросы к сервису должны посылать эту куку в хедере. Теперь вопрос. Предположим, что добрый пользователь залогинившись извлечет свое значение jsessionid ( это обычный текст) и раздаст своим соратникам. Соратники получат доступ к ресурсам. Как этому воспрепятствовать? Весь обмен осуществлять на HTTPS ? Не хотелось бы, потому что большие обьемы данных. |
| Автор: Platon 24.1.2009, 20:42 |
| 1. А в чем угроза такого поведения? 2. Почему бы не привязать к session ID еще и IP? |
| Автор: powerOn 24.1.2009, 20:47 | ||||
Тоже самое, если добрый пользователь даст соратникам свой логин и пароль.
Сканировать сетчатку глаза, брать отпечатки пальцев. Ну или не пускать несколько клиентов с одними и теми же идентификационными данными и разными IP. |
| Автор: ivg 24.1.2009, 20:48 |
| Если пользователь передаёт свою аутентификационную информацию третьим лицам, то никакие технические средства не помогут. jsessionid тут не причем. С таким же успехом он может передать логин/пароль или сертификат для соединения по SSL. |
| Автор: COVD 24.1.2009, 21:11 | ||||||||
Platon
Угроза в том, что доступ к информации оплатит только один.
IP клиента иногда меняется его провайдером и может пострадать вполне законный клиент. powerOn
... одновременно Это правильный подход, т.е. только один пользователь с парой имя-пароль. Этот подход естественным образом реализуется, когда клиенту позволено иметь только одно постоянное соединение с сервером для всех своих нужд. Но это не совсем "сервис ориентед". ivg
В общем, коллеги, вы укрепили мои сомнения, что Kerberos мне товарищ. |
| Автор: Samotnik 25.1.2009, 00:59 | ||
в точку  В этом случае спасет. только защищенный протокол  |
| Автор: Platon 25.1.2009, 15:00 | ||
Правильно подметили, можно раздать логин/пароль. А от себя скажу: Вы наверно неправильно поняли меня. Привязать к сессии IP пользователя. 1. Если еще 1 пользователь подключается с той же sessionId, но с другого IP, то блокируем 2. Если еще 1 пользователь подключается с логином/паролем уже авторизованного пользователя, но с другого IP - блокируем. |
| Автор: COVD 25.1.2009, 16:41 | ||||
Покупается одна лицензия на бригаду. Или публикуется jsessionid .
Первое, что мы стали делать, это записывать в базу ip клиентов. Но потом обнаружилось, что в течении сессии (а это несколько часов) у пользователя может поменяться ip (а sessionId сохраняется, компьютер не перезапускался). Компьютер отправляет два запроса GET с интервалом времени. Каждый раз создается новое соединение с сервером. Сервер видит разные адреса соединений. Если это невозможно, т.е. мы просто ошиблись, то анализ ip решит все проблемы. |
| Автор: Platon 25.1.2009, 16:53 | ||
Сервер видит разные адреса в случае если у провайдера клиента возник сбой и при восстановлении соединения с интернетом провайдер выделяет динамический IP. Согласитесь что это достаточно редкий случай? Урежьте время истечения сессии и сделайте автоматическую авторизацию при просроченной сессии. Добавлено через 2 минуты и 26 секунд Мой провайдер, кстати, выделил мне статический IP. |
| Автор: COVD 25.1.2009, 18:18 | ||||
Ну, наверное, редкий. 365 клиентов, у каждого один раз в год случается какая-нибудь фигня, а на сервере атмосфера, что каждый день проблемы. А бывает, что каждый день у группы товарищей из одной конторы в разгар рабочего дня приблизительно в одно время что-то происходит.
Мне не нравится идея привязки доступа в систему к IP. Но, наверное, тут можно поколдовать. А хотелось сразу готовое индустриальное решение на профессиональном уровне от J2EE. |
| Автор: ivg 25.1.2009, 19:34 |
| Смарт-карты, usb-ключи и т. п., короче что-то, что трудно скопировать, в отличии от логина/пароля |
| Автор: COVD 25.1.2009, 20:20 | ||
Для продукта, распространяемого через интернет (WebStart) , это неудобно. Шаг назад в некотором смысле. Уж лучше пусть подворовывают. Решение то у нас есть - использовать одно постоянное соединение для всех нужд - как для передачи потока данных от сервера, так и для обслуживания однократных запросов клиента. Вопрос возник, когда мы стали выносить обработку однократных запросов в отдельный сервис. |
| Автор: ivg 25.1.2009, 23:36 |
| Подождите, если у вас webstart, то есть приложение на Java, которое может запускаться и без браузера, да даже если с браузером, как по вашему клиент узнает сессионный Cookie? я так понимаю в браузере его не будет (или аутентификация на веб-странице? а как потом этот Cookie передаёте в приложение?), у себя в приложении вы его не показываете, так ведь? Что вы используете? Apache HttpClient? Даже если какой нить кул-хацкер просмотрит сетевой трафик, как он эту куку воткнёт потом? Этож надо фильтр какой-то мастерить или ваш код разбирать и переделывать. Но даже и в этом случае можно просто этот Cookie периодически менять или вообще от запроса к запросу. Ну а вариант с логином/паролем - отпинывать аутентификацию если такой пользователь уже залогинен. Остаётся когда "соратники" будут поочерёдно работать. Ну тут просматривать логи с IP-шниками клиентов, и злостных нарушителей лишать доступа, о чем явно предупредить в лицензионном соглашении или где то там. |
| Автор: COVD 26.1.2009, 05:49 |
ivg. Вы столько предположений сделали. И сами на них же ответили. Причем, правильно.  Кстати, мы довольствуемся HttpURLConnection. Конечно, большинство пользователей не будет возиться с куками. И предложения защиты у вас разумные (только это отнюдь не "просто"). Но, повторюсь, я искал готовое в J2EE. И не потому, что лень программировать, а потому, что пора переходить к стандартным индустриальным решениям. И , наверное, разумно пока использовать form-based , а гурманство отложить до времен, когда это может стать действительно необходимостью. |
