To Сергей Тарасов:
Ну я за три дня размышлений на эту тему что-то подобное вырисовал, но вот идея с шаблонами прав доступа - класс! Меня то больше всего вопрос мучал, что слишком громоздкое решение задачи получается, а хранить только отклонения от шаблона группы в голову не пришло :(
Можно идею поюзать? :-)

По поводу реализации: у Сергея описана только модель, а реализации совсем чуть-чуть. Я кое-что пробовал уже по ходу трехдневного изобретения велосипеда. Использование хранимых процедур действительно удобно (как верно заметил уважаемый Lamer). Создаем login и пароль доступа к БД, под которым будет конектиться наше приложение. Это имя не имеет прав к таблицам, а имеет только доступ к выполнению хранимых процедур, причем в эти процедуры в качестве параметра необходимо передать UID, выданный при вводе logina и пароля доступа к программной системе. (Пользователь вводит логин+пароль, вызывается хранимая процедура, которая в случае правильности ввода возвращает его UID.) Т.е. даже если злоумышленик взломал пароль, под которым приложение конектиться к БД, это не дает ему возможности получить информацию из таблиц данных в обход хранимых процедур. Таким образом получаем два уровня защиты: имя и пароль приложения, имя и пароль пользователя. Два уровня лучше чем один :)
Жду критики по поводу реализации.

P.S. Приложение создается под MSSQL7.0. Все эксперименты соответственно с ним.

Коллеги, несколько лет назад я реализовывал систему безопасности ан TSQL. Возможно вам будет интересно ознакомится с моделью, приведенной в статье.
http://www.arbinada.com/articles.html

Кстати, мой сайт перехал на
http://www.arbinada.com

А еще лучше - хранимые процедуры. Можно и выборки нужные делать. И ограничений меньше ( как отсутствие order by в view ).

В догонку...
Хотя вообще-то это будет ограничение прав доступа на стороне
клиентской части, правильнее все же использовать View.

to Warcat
Сложная система+сложные запросы -> сложная система разграничения прав доступа.
Вообще для каждой таблицы (или для группы таблиц) может быть своя функция проверки, какие строки можно "показывать" данному пользователю, а какие нет.
Для реализации функции разграничения прав доступа возможно потребуются дополнительные "конфигурационные" таблицы.
Что касается рассчетов, то они должны быть реализованы на "стороне" сервера в виде отдельных процедур, функций, пакетов (и т.п.)

to BAV:
100 таблиц, 100 пользователей! + сложные запросы (выводить эту информацию пользователям нельзя, а в расчете она участвовать должна) + делегирование прав от пользователя к пользователю + необходимость это все администрировать. Вопрос в том, какие структуры данных необходимы для вычисления функции "функция_проверки_прав(user)". Вопрос в организации взаимосвязи между объектами и между таблицами. Простой проверкой: if "сидоров" then "выводить информацию" здесь не обойтись. Скорее так: if "сидоров" then "выводить информацию из определенных строк и столбцов, а в расчете применять определенные строки других таблиц". Как и где хранить информацию об "определенных" строках и столбцах?

to All: интересуют не только ршения, но и идеи, модели. Все-таки тема про UML :)

И вообще такая организация системы безопасности реальна?

to Warcat
Выбирать (апдейтить etc) строки, пока функция возвращает определеное значение

Например,
select ...
from ...
where функция_проверки_прав(user)=1;

В самой функции реализуешь проверку что можно пользователю user.
Или я может вопрос не так понял?

to BAV:
Прошу прощения. А нельзя ли подробнее. Каким образом мне поможет функция в условиях запроса? Имеется ввиду в каждом запросе проверять возможность его выполнения для текущего пользователя? А как в таком случае организовать администрирование системы безопасности?

Насчет View: для групп пользователей это действительно хороший вариант (досконально еще не разбирался), но требования ТЗ - разграничение прав на уровне пользователя. А пользователей в системе может быть больше 100. А последнее требование: делегирование прав доступа. :-((( Эх... огрчает меня это.

2Warcat
Может быть использовать функцию в условии запроса?

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