Господа, доброго времени суток.

Существует система документооборота, к которой необходимо прикрутить
секьюрити средствами БД. Хотел посоветоваться как это лучше сделать и
какие технологии предпочтительней использовать.

Дело в том, что :

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

2. Секьюрити должно быть построено не на пользователях, а на группах.
Пользователи прямых привелегий не имеют. Все работает только на уровне групп.

3. Один пользователь может входить в несколько групп сразу.

4. Реализовать это дело необходимо для Оракла (9) и СКЛ Сервера(2000).


Что можно было бы использовать?


Мне очень смутно представляется такая схема:

1. Все таблицы создаются только под админовским экаунтом (в его схеме)

2. Когда происходит грант группе на доступ к какой-либо таблице, то :
а) на самом деле админовская схема (экаунт) создает например хранимую процедуру,
которая будучи создана администратором имеет полный доступ к необходимой таблице,
б) уровень доступа к записи (SELECT, INSERT, UPDATE, DELETE) ограничивает внутри
своего кода.
в) Затем на эту хранимую процедуру даются права EXECUTE группе. Так происходит грант.

г) Сама хранимая процедура должна возвращать видимо курсор с выбранными данными

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

Как реализовать вот это самое ограничение области видимости (WHERE) непонятно.
Очевидно, что нужно прибавить к каждой таблице метаданных системы по столбцу, по которому собственно
и будет происходить ограничение видимости.. типа ID_GROUP.
НО так как количество групп не постоянно (они создаются, удаляются, меняются их привелегии), то одним
столбцом четко идентифицирующим группу не обойдешся.. Можно в этом столбце на битовом уровне
содержать маску, которая бы описывала бы все группы, имеющие отношение к этой записи, а затем идти в спец. таблицу метаданных описывающих группы и их права и считывать все эти вещи отдельно..


Короче, что-то все слишком мутно и сложно... - одни расплывчатые идеи.

В Оракле смотрел Fine Granted Access Control - вроде и подходит и не подходит.. - непонятно.
Что смотреть у МС СКЛ не знаю.

Далее.. Если делать секьюрити на уровне записей, когда, как в моем случае, рекордсеты транслируются через
уровень хранимых процедур + условие WHERE довольно сложное и идет по нескольким таблицам,
подразумеваю, что должно быть бешенное падение производительности - она же имеет очень серьезный приоритет
(производительность). Возможно каким-то образом можно привинтить материализованные вью или ещё что, что
позволит оставить скорость выборки данных на уровне..


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

PS
Хочется решить задачу применительно к каждой из описываемых СУБД отдельно, используя самые сильные
её стороны, заточенные специально для данных задач.

Спасибо.