Разграничение прав доступа на уровне записей

Добрый вечер всем!

Пытаюсь написать систему электронного документооборота
клиент на Delphi БД Firebird с функциональностью вроде придумал как и что
а вот как организовать систему доступа. Понятно что на такой вопрос в
форуме не ответишь, меня интересуют ссылки на статьи по этой теме
присоветуйте кто, что видел.

Заранее спасибо.

ЗЫ. тип сервера неважен пока думаю над концепцией

Каждый выбирает для себя сам.... :)
ИМХО, надо делать разграничение на уровне приложения, т.к. на уровне сервера можно решить (за разумную затрату сил) только малую часть этих вопросов.

Пользователей собирать в группы. Права назначать на эти группы. Точно также поступать с разделяемыми сущностями:
Товары - в группы
Контрагентов - в группы
Документы с важными признаками - в группы

Найти запросом пересечение "ПользовательГруппа" и "КонтрагентГруппа" не составит труда ни для программиста ни для сервера. Можно ввести понятие "Public-признак" т.е. "доступен для всех групп пользователей" (если разделение прав пока не актуально). Постараться без нужды не плодить сущности и группы.
Создать удобный механизм изменения/копирования/объединения/исключения прав в группах.

Получится ОЧЕНЬ гибко и умеренно трудоёмко, вне зависимости от платформы на сервере и клиенте.
ИМХО, это единственный способ сделать безопасность и ПРОСТО и ГИБКО для систем с большим числом сущностей и сложными требованиями к безопасности.
Прошу не начинать флейм про права на сервере, аутентификацию и пр.
Тут нет "серебряной пули".

nnov

Разграничение прав доступа на уровне записей

Нет такой возможности в сервере.
Делай на клиенте.

www.ibase.ru/devinfo/treedb2.htm

Привет, kdv!
Ты пишешь:

kdv

k> www.ibase.ru/devinfo/treedb2.htm

Дмитрий!
Ты же уже должен быть мертвецки пьян! ;)

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

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

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

Речь идет о разграничении прав доступа НА УРОВНЕ ЗАПИСЕЙ (т.е. row-level security). Стандартных средств у серверов баз данных нет. Впрочем, система прав доступа для достаточно крупной информационной системы мощнее, чем предлагаемая серверами баз данных.

Кроме того, кроме ограничений x=1, x=2, могут быть ограничения и по времени работы с различными объектами информационной системы.

Один из возможных подходов - использование хранимых процедур. На выполнение хранимых процедур дать доступ пользователям, на таблицы -запретить.

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

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

Результат проверки прав доступа может вернуть не просто "да" или "нет", а какое-либо условие (x=1). Результирующую выборку отфильтровать с использованием данного условия. И вернуть клиенту.

2 igorolv,
как-то срашновато звучит.

Скажите, вы использовали это в своих проектах? Сколько юзеров с различными правами у вас было?

автор

Результат проверки прав доступа может вернуть не просто "да" или "нет", а какое-либо условие (x=1). Результирующую выборку отфильтровать с использованием данного условия.

Попахивает Execute statement...

[quot igorolv]Ограничение прав доступа на сервере надежнее.

Из этих соображений я и решил порыть в данном направлении
до недавнего времени я работал в банке и обслуживал банковскую систему
где подобное было реализованно на Oracle правда при использовании коммерческой двоичной библиотеки.
Но принцип в следующем: права на таблицы только у админа пользователям даются права только на процедуры и вьюшки при запросе на выполнение процедуры или вызове VIEW проверяются права Права могли назначатся очень гибко на уровне документа и даже на уровне отдельных операций над документом. И что самое главное абсолютно неважно через какого клиента ты работаешь с данными.
Поэтому реализация на клиенте очень ненадежна. Подключи через ODBC в Access базу и правь данные как хочешь... Так непойдет, и тратить время на реализацию на клиенте безсмысленно это показуха, а не защита.
Я тут нашел неплохую статейку, но маловато еще бы таких примеров
www.delphiplus.org/articles/ib/only_for_your_eyes/index.html

маловато таких примеров

я уже давал ссылку. не катит?
www.ibase.ru/devinfo/treedb2.htm

тут как раз в том числе упоминается мандатная защита Oracle и Linter.

я уже давал ссылку. не катит?
www.ibase.ru/devinfo/treedb2.htm

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