iAndrew - пользователи оформлены как Системные пользователи Оракла с минимальными привилегиями.
Правильно.

iAndrew - когда пользователь захочет вставить данные - он делает exec Procedure (которые конешно в пакеджах будут забиты).
Допустимо. Хотя если в тупом варианте типа "процедура insert с параметрами, соответствующими вставляемым полям" - дурная лишняя работа.

iAndrewЗатем система обработает пользователя - посмотрит его уровень доступа из служебной таблицы - и если всё ок - вставит данные в систему..
Хреново. Очередной "велосипед своими руками".

Ссылки на статьи.... собственно, в документации Oracle большая книга посвящена именно настройке безопасности.

Кратко:

- Нормальным образом настраиваются роли и гранты пользователей.

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

- Настройка прав на строки таблиц делается предпочтительно через VPD (Virtual Private Database). Менее удачный, но допустимый вариант - updateable view, скрывающие реальные таблицы. В обоих случаях нужен какой-то набор настроек - собственных таблиц, которые определяют "кому что можно". В любом случае, пользователь имеет именно тот набор данных, которыми он может оперировать.

- Если есть проверки, которые нежелательно вносить в политики доступа (например, из-за долгого времени проверки), они делаются на триггерах.

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

- Хранимый код по необходимости следует делать выполняющимся с правами вызывающего.

iAndrewМожно какойнить небольшой примерчик таблички бизнес-функций?..
Хм.

idНазвание1Работа с товарными накладными2Расчет зарплаты3Заказ пиццы в офис......

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

iAndrewVPD = FGA?
Насколько я помню, VPD = FGAC = RLS, а FGA - это чуть другое :) Впрочем, я не чувствую себя полностью уверенно во всех этих страшных буквах :)

iAndrew Если так, то на эту технологию нужны какиенить дополнительные лицензии?
Не помню. Посмотрите в прайс-листе - продается ли она как часть EE или как отдельная опция.

iAndrew Опять же, можно какойнить примерчик про такие таблички..
Это уже слишком зависит от того, какую логику следует заложить в ограничение прав. Например, хотите назначать каждому пользователю склады, с которыми он может работать - значит, делаете развязку между пользователями и складами. Итп.

iAndrewно ведь у меня в Модели подобная табличка использовалась - Называеться "Возможность".
Безусловно. В Вашей модели неправильным было в основном желание самостоятельно проверять то, что можно и нужно доверить серверу. Что же до конкретной структуры таблиц - ее надо смотреть применительно к задаче.

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

iAndrew Как можно сделать такую вещь - чтобы внесенную строку мог редактировать только её Автор или его друг? а другие её редактировать не могли..

Увы по Fine Granted Acces Control примера хорошего не нашел.. нашел лишь пример когда может редактировать лишь один автор.
Хм. Собственно весь вопрос в том, чтобы сформулировать требуемое условие как SQL-выражение политики. Нужен друг - опишите это понятие в терминах запроса. Ну и не менее актуальный вопрос - сформулировать его так, чтобы не убить производительность доступа к этой таблице.