Добрый день, marlis82!

> Есть 2 варианта реализации:
> 1. Авторизация в oracle и доступ к ресурсам через Гранты СУБД. Но в
> таком случае возможно ли для каждого пользователя создать одно
> соединение к базе и соотвественно убивать его при выходе сессии на
> стороне аппликейшна.

Это убивает многие вещи, стандартные для AS- пул коннектов, JMS будет
работать непонятно как и т.п.

> 2. Авторизация средствами аппликейшна но база пользователей будет уже не
> базой реальных пользователей СУБД простой таблицей с паролями и правами.

Да, логично.

> Соотвественно в таком случае для определения прав на те или иные объекты
> в базе будет написана процедура в СУБД которой необходимо передавать
> каждый раз при обращении к ресурсам пользователей логин пользователя.
> Возможна ли такая реализация?

Не надо. На каждую операцию делается @RolesAllowed.
При логине заполняем (есть пример в jboss'е) имена доступных ролей из
таблицы БД.

И далее проверка прав идёт без обращения к БД.

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

> И конечно же в таком случае, случае неиспользования JAAS возникает
> необходимость ставить фильтры на каждую страницу для определения
> доступно ти для текущего юзера.

Да. Если идти в AS "процедурно/датабазным" путём то грабли обязательно
стукнут по лбу.

--
Алексей
JID: alxt@ya.ru
Posted via ActualForum NNTP Server 1.5

Добрый день, marlis82!

> Я правильно понял - сначала настраивается JAAS только не по
> пользователям, а по ролям, таким образом ролевые доступы прописываются в
> конфиг файле, дальше при логине пользователя, ему маппится определенная
> роль, имеющаяся в СУБД и соответственно в JAAS. В таком случае нет
> необходимости каждый раз ставить фильтры на новые страницы?

Не совсем. Пользователю сопоставляется набор ролей. На каждую операцию
даются права одной (ну или нескольким) ролям.
Пользователя и список ролей можно связывать через "группы ролей" к примеру.

> Как это реализовать? Как использовать @RolesAllowed? Есть ли ссылка
> краткая по использованию?

Да полно. Гугл весь пестрит ссылками.
По сути на реализацию метода пишешь



И так далее. Потом в таблицах пишешь список ролей ("Entity1.put.new" и
т.п.), рядом список логинов, таблицу групп ролей и связку операторов и
групп.
Админ настраивает группы, даёт операторам права на группы, а в
логин-модуле ты по списку групп получаешь роли и пишешь их в методе,
реализующем LoginModule.commit в Subject. Подробности- это зависит от
сервера. Я только с jboss знаком.

> Используем Weblogic в качестве апп. сервера, а среда разработки JDeveloper.

Среда разработки не важна вообще, а Weblogic я не знаю.
В жбоссе список ролей заполняется так (что-то общее, что-то придётся
переделать).
Список ролей- просто массив строк roleList, полученный как-то...
Subject subject - то, что передаётся в LoginModule.initialize




--
Алексей
JID: alxt@ya.ru
Posted via ActualForum NNTP Server 1.5

Добрый день, just_vladimir!

>> Реализовывать безопасность на уровне базы данных при наличии сервера
>> приложений - для этого должны быть веские причины, например, наличие
>> клиентов, имеющих прямой доступ к базе.
>
> У нас например есть такое требование со стороны безопасности, что
> разграничение прав доступа должно дублироваться на каждом из уровней,
> при том, что у пользователей есть доступ только до AS.

А чем оно обосновано? Или они просто не понимают сути происходящего?

>> Это убивает многие вещи, стандартные для AS- пул коннектов, JMS будет
>> работать непонятно как и т.п.
> Proxy authentification, не?

Это когда при каждой операции сессии даются права, соответствующие
пользователю?
Мне думается, это приведёт к фантастическим тормозам.

--
Алексей
JID: alxt@ya.ru
Posted via ActualForum NNTP Server 1.5

Добрый день, just_vladimir!

> Формально - нормативными документами организации. А так высокая
> секретность -> высокая цена ошибки приводящей к утечке. Пример, криво
> написанное приложение затесалась уязвимость на sql-injection (или любая
> другая, не важно как такое получилось, за всем не уследишь, нет
> идеальных технологий/продуктов, не имеющих уязвимостей, что-нибудь,
> где-нибудь да найдется), то должна сработать защита на следующем уровне.

Понятно. Нам, пока, к счастью такое требование не выставляют.

> Ну может думаться по разному ;-) А так, экономия на спичках, т.к.
> прибавка к накладным расходам на операцию константная (конечно же не для
> случая, когда у вас тыс/млн запросов в секунду).

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

--
Алексей
JID: alxt@ya.ru
Posted via ActualForum NNTP Server 1.5