Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
DB2, трехзвенка, авторизация
|
|||
|---|---|---|---|
|
#18+
Добрый день, друзья ! Решил испросить совета и услышать мнения и опыт вот по какому вопросу. Планирую трехзвенное приложение db2 + java (websphere) + html. Раздумываю сейчас об авторизации пользователей. Раньше работал с ораклом, где все было просто и понятно - пользователи хранятся в базе, права на объекты базы привязаны к этим пользователям и.т.д. Т.е. авторизация выполнялась однозначно на уровне базы. В случае с DB2 ситуация немного иная, т.к. база использует системных юзеров и к ним привязываются все привилегии. Использование LDAP , в принципе, немного облегчает жизнь, но не сильно (те же системные пользователи только в профиль). Раньше, работая с ораклом , при добавлении юзера, мне приходилось выполнять следующие операции: - создание пользователя в базе - предоставление пользователю определенной роли - создание записи о юзере в одной таблице (чтобы на username мог выступать как внешний ключ в других таблицах) вот, в принципе и все. Все это могло делаться из самого приложения. просто и приятно. Здесь же получается немного сложнее, т.к. создание системного пользователя из приложения невозможно, следовательно, трудно реализуем т.н. "админский интерфейс" в приложении. Использование LDAP решает эту проблему, но тогда возникает проблема с переносимостью приложения на другую систему (а переносить приложение иногда, как это ни прискорбно, приходится). Использовать традиционный подход веб-програмистов, работающих с мускулом и.т.п. , когда всеми объектами в базе владеет один пользователь, а весь контроль доступа определяется не базой а приложением, тоже не хотелось бы (почему бы этим не заняться базе ?;-) ) Какой подход используете вы ? Что было бы правильным в данной ситуации. Сам, пока , вижу выход только в использовании LDAP , но - см. выше. P.S. Прочитал обсуждение на эту тему в ветке оракла, можно не тынцкать, т.к. оракл - в нем все по-другому (см.выше) :) Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 14:15 |
|
||
|
DB2, трехзвенка, авторизация
|
|||
|---|---|---|---|
|
#18+
LDAP универсальная штука, у которой проблем с переносимостью меньше всего. Авторизация, используя пользователей СУБД - системных пользователей - технология прошлого тысячелетия. Лучше забыть об этом. И не вспоминать. В Java всё как в "традиционный подход веб-програмистов, работающих с мускулом" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2008, 16:06 |
|
||
|
DB2, трехзвенка, авторизация
|
|||
|---|---|---|---|
|
#18+
chroLDAP универсальная штука, у которой проблем с переносимостью меньше всего. Согласен. поэтому использую именно лдап. chro Авторизация, используя пользователей СУБД - системных пользователей - технология прошлого тысячелетия. Лучше забыть об этом. И не вспоминать. В Java всё как в "традиционный подход веб-програмистов, работающих с мускулом" Хмммм.. а что насчет разделений прав доступа к объектам внутри БД ? Или этим тоже пользовались только в прошлом тысячелетии ? ;-) Это заботит меня в первую очередь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2008, 16:16 |
|
||
|
DB2, трехзвенка, авторизация
|
|||
|---|---|---|---|
|
#18+
1. СУБД должна аутентифицировать/авторизовывать тех, кто работает с СУБД. 2. По классической схеме работы веб-приложений, веб-пользователей может быть очень много, но при этом у них у всех практически идентичные права в СУБД, поэтому для пользователей настраивается общий пул соединений с общим логином в СУБД. Как правило, для каждого приложения логин в СУБД будет свой. Можно и несколько пулов настроить с разными логинами. 3. Настроить и WAS и DB2 на работу с LDAP-сервером рекомендуется. Привязываться к базе пользователей внутри ОС не очень хорошо, переносить/расширять сервер будет сложнее. 4. Для случая, когда требуется пропагация пользователя в DB2, есть решение для WAS 6.1 и DB2 9.5. Называется это решение Trusted Context или Trusted Connections. За подробностями - в документацию. Сами пока Trusted Context на практике не опробовали, только собираемся. PS: Общий подход заключается в том, что J2EE-программист не должен "закладываться" на логин пользователя. Есть понятие ролей, которые можно и нужно использовать. Есть понятие JNDI-ресурса, за которым "скрыт" пул соединений, очередь сообщений, или другой ресурс. А где расположена база пользователей и как происходит аутентификация/авторизация на сервере приложений - это головная боль администратора сервера приложений, но не разработчика приложения. Где-то аутентификация это логин-пароль, где-то сертификат, где-то стороннее решение. То же относится и к ведению базы пользователей. Для более сложных случаев, когда необходимо чтобы дополнительную проверку прав производила СУБД DB2 - смотри пункт 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2008, 16:33 |
|
||
|
DB2, трехзвенка, авторизация
|
|||
|---|---|---|---|
|
#18+
Евгений Хабаров 3. Настроить и WAS и DB2 на работу с LDAP-сервером рекомендуется. Привязываться к базе пользователей внутри ОС не очень хорошо, переносить/расширять сервер будет сложнее. Сам много читал и думал, что надо бы сделать авторизацию средствами LDAP. В последнее время всё больше посещают мысли - а зачем? На JavaEE нам нужен только один пользователь. На сервере БД два локальных пользователя - владелец инстанса и админастратор. Под управлением Windows, мы имеет Active Dicrectory, что по существу является LDAP. Под Linux имеем Samba 4 Active Directory - тот же LDAP. Зачем обходить доменную авторизацию, если она сма работает через LDAP? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2008, 20:27 |
|
||
|
DB2, трехзвенка, авторизация
|
|||
|---|---|---|---|
|
#18+
galsЕвгений Хабаров 3. Настроить и WAS и DB2 на работу с LDAP-сервером рекомендуется. Привязываться к базе пользователей внутри ОС не очень хорошо, переносить/расширять сервер будет сложнее. Сам много читал и думал, что надо бы сделать авторизацию средствами LDAP. В последнее время всё больше посещают мысли - а зачем? На JavaEE нам нужен только один пользователь. На сервере БД два локальных пользователя - владелец инстанса и админастратор. Под управлением Windows, мы имеет Active Dicrectory, что по существу является LDAP. Под Linux имеем Samba 4 Active Directory - тот же LDAP. Зачем обходить доменную авторизацию, если она сма работает через LDAP? Домен - это уже централизация авторизации. Я говорил про нежелательность авторизации в Standalone OS. И помнится мне, что к Active Directory можно отлично ходить по LDAP-протоколу. Ну и если ОС-авторизация централизована, никто не мешает и ОС-авторизацию использовать. Насчет того, что в J2EE один пользователь я что-то не понял. Это что имеется в виду? А веб-пользователи (кто использует веб приложения) туда не входят? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2008, 10:44 |
|
||
|
DB2, трехзвенка, авторизация
|
|||
|---|---|---|---|
|
#18+
Евгений Хабаров Насчет того, что в J2EE один пользователь я что-то не понял. Это что имеется в виду? А веб-пользователи (кто использует веб приложения) туда не входят? Для подключения к БД используется один пользователь. У него права высталены по максимуму, для того, чтобы любая часть приложения (Jave EE серверное приложение) могло нормально функционировать. Аутентификация и авторизация идут на уровне приложения. За это отвечает система безопасности Application Server (WEB Server). У каждого пользователя свой набор прав на использование частей приложения. Такой подход к базе данных оправдан. Пользователь работает в режиме вопрос/ответ. Сервер приложения использует Java Datasource - пул конекций. Когда инициируется действие, приложение запрашивает у пула соединение с БД. В конце действия идет завершение транзакции и команда закрытия конекции. На самом деле, соединение не рвется, а возвращается в пул (Datasource). В настройках подключения к БД указывается максимальное количество физических коннекций к БД, которое можно установить с БД. Указывается минимальное количество удерживаемых коннекций. Не кажется ли вам, что это напоминает буфер коннекций самой БД? DB2 не закрывает соединения, а передает его новому пользователю. Различие состоит только в подходе JavaEE - один пользователь, DB2 - много пользователей, а соединение одно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2008, 19:34 |
|
||
|
DB2, трехзвенка, авторизация
|
|||
|---|---|---|---|
|
#18+
galsЕвгений Хабаров Насчет того, что в J2EE один пользователь я что-то не понял. Это что имеется в виду? А веб-пользователи (кто использует веб приложения) туда не входят? Для подключения к БД используется один пользователь. У него права высталены по максимуму, для того, чтобы любая часть приложения (Jave EE серверное приложение) могло нормально функционировать. Аутентификация и авторизация идут на уровне приложения. За это отвечает система безопасности Application Server (WEB Server). У каждого пользователя свой набор прав на использование частей приложения. Такой подход к базе данных оправдан. Собственно о такой организации взаимодействия J2EE приложения с СУБД я и писал выше. Подход вполне оправдан конечно. С этими позициями я спорить и не собирался. Вопрос в предыдущем посте ставился иначе, поэтому у меня и возник встречный вопрос. При централизации базы пользователей имеет смысл всех веб-пользователей тоже держать в общей базе. Т.е. предположим что в Вашей организации центральным звеном аутентификации/авторизации является Active Directory. Предположим, что J2EE-приложение является внутренним (корпоративным), т.е. пользователи этого приложения есть (или должны быть) в базе Active Directory. В таком случае, будет вполне оправдана настройка сервера приложения на взаимодействие с Active Directory, чтобы пользователь J2EE-приложения мог зайти в это приложение под своим доменным логином и паролем. Я хочу сказать, что в этом случае, будет излишним заводить отдельную базу пользователей внутри сервера приложений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 09:50 |
|
||
|
DB2, трехзвенка, авторизация
|
|||
|---|---|---|---|
|
#18+
что касается централизованной авторизации - она у меня существует. Это удобно и вполне переносимо. Больше интересовало разделение прав именно внутри БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 11:33 |
|
||
|
DB2, трехзвенка, авторизация
|
|||
|---|---|---|---|
|
#18+
Решение завязаться на базе данных - это не совсем хорошо Первые заморочки, скорей всего, начнуться как только понадобится какое нибудь SSO. Для целей авторизации и аутентификации правильнее использовать J2EE security / JAAS. 1. Получаете пренесимость (все j2ee сервера приложений поддерживают эту спеку) 2. Получаете ролевой доступ к бизнес методам и компонентам в целом. 3. Ваш Realm может быть где угодно (база данных, LDAP, виндовый реестр, файл и т.п. и т.д.). Вот как то так... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2008, 11:44 |
|
||
|
DB2, трехзвенка, авторизация
|
|||
|---|---|---|---|
|
#18+
sapounovчто касается централизованной авторизации - она у меня существует. Это удобно и вполне переносимо. Больше интересовало разделение прав именно внутри БД. Я же говорю, есть такая штука как Trusted Context (WAS 6.1 + DB2 9.5 for LUW (или DB2 9.1 for z/OS)). Но - это будет привязка к DB2, т.к. в первую очередь требуется поддержка со стороны СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2008, 13:04 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=35652337&tid=1603565]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
52ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 218ms |
| total: | 355ms |

| 0 / 0 |
