Теория: Распределение прав

[skiperski]

Решил расставить точки над i с правами и ролями пользователей. Есть несколько вопросов.

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

Всего объектов к которым необходимо определить доступ девять. Они могут быть сгруппированы по двум признакам: по принадлежности к проекту и по принадлежности с типу документа (эскиз, программа, отчёт).

Код: Выделить всё

Файлы          ¦ Дизайнеров (Д) ¦ Кодеров (К) ¦ Менеджеров (М)
------------------------------------------------------------------
проекта А (АА) ¦       ДА       ¦      КА     ¦      МА
проекта В (ВВ) ¦       ДВ       ¦      КВ     ¦      МВ
проекта С (СС) ¦       ДС       ¦      КС     ¦      МС

Права будем давать не каждому пользователю, а группе.

Код: Выделить всё

Все сотрудники                [DENY: ALL] (запретить: все)
+-Разработчики проекта А      [ALLOW: АA] (разрешить: все файлы проекта А)
¦ +-Дизайнер А
¦ +-Программист А
¦ +-Менеджер А
+-Разработчики проекта B      [ALLOW: ВB] (разрешить: все файлы проекта B)
¦ +-Дизайнер B
¦ +-Программист B
¦ +-Менеджер B
+-Разработчики проекта C      [ALLOW: СC] (разрешить: все файлы проекта C)
¦ +-Дизайнер C
¦ +-Программист C
¦ +-Менеджер C
+-Менеджеры                   [ALLOW: М] (разрешить: все отчёты всех проектов)
¦ +-Менеджер A
¦ +-Менеджер B
¦ +-Менеджер C
+-Дизайнеры                   [ALLOW: Д] (разрешить: все эскизы всех проектов)
¦ +-Дизайнер A
¦ +-Дизайнер B
¦ +-Дизайнер C
+-Программисты                [ALLOW: К] (разрешить: все программы всех проектов)
¦ +-Программист A
¦ +-Программист В
¦ +-Программист С

Здесь всё с правами ясно и понятно.

Теперь предположим, что проект В засекретили. Как должны распределиться права?

Мой вариант:

Код: Выделить всё

Все сотрудники                [DENY: ALL] (запретить: все)
+-Разработчики проекта А      [ALLOW: АA] (разрешить: все файлы проекта А)
+-Разработчики проекта B      [ALLOW: ВB] (разрешить: все файлы проекта B)
+-Разработчики проекта C      [ALLOW: СC] (разрешить: все файлы проекта C)
+-Менеджеры                   [ALLOW: М, DENY: BB] (разрешить: все отчёты всех проектов, запретить: все файлы проекта В)
+-Дизайнеры                   [ALLOW: Д, DENY: BB] (разрешить: все эскизы всех проектов, запретить: все файлы проекта В)
+-Программисты                [ALLOW: К, DENY: BB] (разрешить: все программы всех проектов, запретить: все файлы проекта В)

Теперь появилась неоднозначность. Например для дизайнера В, с одной стороны доступ разрешён, т.к. он входит в группу "Разработчики проекта B", с другой - запрещён, т.к. он входит в группу "Дизайнеры". Если считать, что приоритет запрета выше приоритета разрешения, то в итоге Дизайнер В не получит доступа к файлам группы В. То же самое можно сказать и по отношению Программист В и Менеджер В. Как решаются подобные конфликты?

Кроме того, если групп много и их вот так как в примере не охватить одним взглядом, то можно запросто пропустить группу которой нужно запретить доступ к документам проекта В.

[GSerg]

Эти проблемы в винде решаются очень просто.
Список прав доступа, ACL, сканируется от начала до конца. Первая встреченная запись о праве на ресурс выигрывает. Поэтому система всегда упорядочивает свои ACL так, чтобы запрещаюшие записи шли перед разрешающими.
Можно воспользоваться той же схемой.

[skiperski]

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

Либо надо устанавливать права непосредственно объектам доступа, т.е. в примере ДА, ДС, КА, КС, МА и МС, либо давать права не группам пользователей, а самим пользователям.

А можно ли сделать правильно так чтобы не менять условия задачи?

[Ennor]

Все сотрудники [DENY: ALL] (запретить: все)

Вот это - лишнее. Нет нужды давать явный deny - достаточно не дать grant. Подумай об этом .

[skiperski]

Это я сэкономил строчку на описании. Конечно же там никаких установок прав нет, это значение по умолчанию или, если угодно, стартовое. Но суть вопроса от этого не меняется.

[GSerg]

Вопрос был как сделать правильно - а что в данном случае правильно?

Возможно, правильно будет поступить наоборот и писать сначала разрешающие, потом запрещающие. Получится искомое, нет?

[alibek]

А есть ли в раздаче прав наследование?

[Ennor]

И вообще - на какой платформе это все реализуется? Это файловая система, это СУБД, это CVS - что?

[skiperski]

И вообще - на какой платформе это все реализуется? Это файловая система, это СУБД, это CVS - что?

Извиняюсь, забыл. Это СУБД. Точнее какой-либо прикладной продукт типа портала, магазина и т.п.

Вопрос был как сделать правильно - а что в данном случае правильно?

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

Возможно, правильно будет поступить наоборот и писать сначала разрешающие, потом запрещающие. Получится искомое, нет?

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

А есть ли в раздаче прав наследование?

Планируется, но пока для упрощения задачи не рассматривается. И я не вижу как наследование может что-то кардинально изменить в данной задаче.

Поясню цель темы. В теории описывается множество различных подходов, на практике же обычно их число ограничено требованиями задачи. Простейший подход с присвоением прав каждому пользователю и объекту позволяет решать любые задачи, но оборачивается непомерным увеличением админской работы, т.к. пересечение объектов (пользователи, права, объекты доступа) даёт декартово множество. Так, только для десяти пользователей системы которая оперирует только пятьюдесятью объектами и предоставляет только пять вариантов прав доступа, администратору необходимо обработать объединение в 10*50*5=2500 записей!

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

Рассматриваемое решение постороено на утверждении, что права или роли на группу объектов назначаются только группам пользователей. Запрет, при прочих равных, имеет больший приоритет чем разрешение. Наследование не рассматривается, т.к. оно имеет смысл только для объектов одной иерархии внутри неё самой, т.ч. для внешних объектов в итоге все унаследованные права будут выглядеть как простой набор прав или как новая роль.

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

Ссылки по теме:
http://www.citforum.ru/programming/digest/access.shtml
http://p-stone.ru/libr/internet/prog/php/data/public17/index.shtml?minimal
http://popoff.donetsk.ua/text/work/libs/passport/privilege/admin.html

[GAGArin]

Если считать, что приоритет запрета выше приоритета разрешения

Почему не наоборот? И почему не задавать уровни приоритета. Т.е. Засекречивание изменяет всем приоритет доступа -1 Разрешение для группы В изменяет приоритет доступа +2 в данном случае. Если дизайнерам нельзя писать ни при каких условиях например изменяем им приоритет -3
Т.е. не просто разрешит/запретить, а разрешить/запретить с уровнем важности разрешения/запрета.

[skiperski]

Если считать, что приоритет запрета выше приоритета разрешения

Почему не наоборот?

Почемучто мы исходим из утверждения, что всё что не разрешено - запрещено, и, если запрещено где-то, то запрещено везде. Это только в этом примере чисто интуитивно мы чувствуем, что тем кто непосредственно работает над проектом необходимо дать права доступа вне зависимости от их вхождения в любую другую группу. Для алгоритма же это совсем не очевидно и даже наоборот.

Пожалуй приведённый пример сложноват для восприятия. Его можно упростить не меняя сути задачи. Чтобы совсем не цепляться за старый полностью изменю его наполнение.

Раньше, не знаю как сейчас, в ВУЗах были, так называемые, вторые отделы. Уж не знаю какие там были документы, но явно не общего пользования. Теперь допустим, что некоторые представители этого второго отдела (группа "чексты") подрабатывают преподавателями на кафедре Марксизма-Ленинизма (группа "преподаватели"). Имеем некий секретный документ. Итак, с одной стороны, как чекисты, они имеют право на его просмотр, с другой, как преподавателям, им доступ запрещён.

В этом примере, как и в предыдущем, логично всем чекистам, вне зависимости от их принадлежности другим группам дать права на просмотр. Т.е. по твоему сделать "наоборот".

Расширим пример. В ВУЗе появились "неблагонадёжные" элементы. Им необходимо перекрыть доступ, может быть временно на период проведения проверки, к секретным и другим выжным документам. Таким образом, в данном случае принадлежность к группе "неблагонадёжные" должна запрещать доступ всем в неё входящим (чекистам, преподавателям, студентам, ректорам и т.д.), не смотря на то, что в человек всё же состоит в группе "чекисты".

Вот две ситуации со схожими условиями: в одной группе доступ разрешён, в другой - нет. Каков будет результат объединения этих прав зависит только лишь от нашей воли при составлении алгоритма. Но он (алгоритм) должен быть однозначным. Чтобы разрешить конфликт (при сходных условиях один раз - да, другой - нет) придётся либо директивно оставить только один из вариантов, либо расширить алгоритм ещё одним правилом. Пока печатал появилась мысль о задании приоритета групп (надо будет её подумать). Тогда будут приняты права группы имеющей высший приоритет. Примениетльно к данному примеру порядок приоритетов групп: "неблагонадёжные", "чекисты", "преподаватели". Надо будет подумать об отношениях групп разных уровней в разных иерархиях. И о возможности зацикливания или линейности приоритетов. Иначе может получиться треугольник: камень, ножницы, бумага. Опять же, приоритеты придётся выстраивать для каждого объекта доступа, т.к. по отношению к секретным документам выше приведённая последовательность верна, а по отношению, например, принятия решения в учебной части расклад будет другим, там первое слово будет за преподавателями. Снова усложнение алгоритма, снова декартово множество. Эхе-хе, хе-хе.

И почему не задавать уровни приоритета. Т.е. Засекречивание изменяет всем приоритет доступа -1 Разрешение для группы В изменяет приоритет доступа +2 в данном случае. Если дизайнерам нельзя писать ни при каких условиях например изменяем им приоритет -3
Т.е. не просто разрешит/запретить, а разрешить/запретить с уровнем важности разрешения/запрета.

Это существенно усложнит администрирование. И совсем не однозначно. Почему разрешение для группы В изменяет приоритет на +2, а не, скажем, на +10? Если дизайнерам установили приоритет в -3, то дизайнер группы В не получит доступа (+2-3) к своим документам в проекте В над которым он имеет право работать.

Потом, как это должно выглядеть в смысле интерфейса? Сейчас, имея объект доступа и группу пользователей, установить между ними определённые отношения: имеет/не имеет право доступа, право редактирования, администрирования и т.п. можно стандатрными чекбоксами. А как это будет выглядеть с приоритетами? Право на редактирование +10, запрет на администрирование -5?

[GSerg]

Хм...
Опять же, ответ уже был озвучен?

Если нет записей о правах: доступ закрыт (наименьший приоритет)
Если есть только разрешающая запись: доступ открыт (средний приоритет)
Если есть запрещающая запись: доступ закрыт (высший приоритет).

В предыдущем примере, группе "преподаватели" разрешений не роздано никаких. И они не могут читать секретные документы (неявный запрет). Группа "чекисты" имеет разрешение на чтение, который всегда выигрывает у неявного запрета. Группа "неблагонадёжные" имеет явный запрет на чтение, который всегда выигрывает у явного разрешения разрешения, если оно есть.

[GAGArin]

Это существенно усложнит администрирование. И совсем не однозначно. Почему разрешение для группы В изменяет приоритет на +2, а не, скажем, на +10? Если дизайнерам установили приоритет в -3, то дизайнер группы В не получит доступа (+2-3) к своим документам в проекте В над которым он имеет право работать.

На счет дизайнера группы В: Да не получит, но это просто уже расширение твоего примера (считаем проект В чекистами, а дизайнеров неблагонадежными ). Если рассматривать твой пример, то дизайнеров просто трогать не стоит.

Вместо +2 можно (и нужно) ставить +10 чтобы при необходимости можно было внести изменения среднего уровня между +1 и +10 Или сделать чтобы при вводе приоритета +2,5 прога сама переписывала приоритеты снова на целочисленные.

Такой системой можно однозначно установить приоритеты всем кого можно вычислить по наличию/отсутствию групп, но если система прав очень сложная, то дописывать её будет тоже весьма сложно. Хотя можно и оптимизировать и частично алгоритмизировать.

[alibek]

Приоритеты не нужны.
Вполне удачная схема была реализована MS, можно использовать ее.
Разве что можно усовершенствовать ее, задавая пользователю (администратору) устанавливать порядок ACL (админ имеет возможность выстроить запрещающие и разрешающие записи в произвольном порядке). Это несколько усложнит администрирование, но не настолько, как с приоритетами.
Можно параллельно к ACL добавить еще два слоя -- роли и профили. Выглядеть это будет примерно так.
Есть группа "преподаватели", группа "чекисты" и группа "неблагонадежные". У каждой их групп есть свои явно разрешающие права (у первых двух) и явно запрещающие права (у последней).
Создается роль (таблица M-M), в которой описывается, к какой конкретной группе относить конкретного пользователя для доступа к конкретному объекту. Профили же используются для того, чтобы делать привязку роли не к конкретному объекту, а к произвольному набору объектов (профиль -- набор ролей).

Но лично я бы выбрал так, как это сделано в Windows (то, что предлагал GSerg во втором посте). Схема достаточно гибкая и в то же время не слишком сложная в использовании.

[GAGArin]

админ имеет возможность выстроить запрещающие и разрешающие записи в произвольном порядке

Не хочу быть настырным, но выстраивание записей в произвольном порядке всего лишь задает строчке n приоритет 2^n не больше. Установка приоритетов "ручками" дает большую гибкость.

[skiperski]

Хм...
Опять же, ответ уже был озвучен?

Для ленивых, чтоб по ссылке не мотаться

Нет нужды давать явный deny - достаточно не дать grant.

Так-то оно так, но получается, что стоит только по каким либо причинам явно запретить группе "преподаватели" использование секретных документов, сразу же все чекисты-преподаватели теряют к ним доступ. А такая ситуация может сложиться в случае, если объекты доступа описаны в пересекающихся иерархиях. Например, при описании док-ов в одной иерархии, скажем "секретность" можно расписать как документы "общего пользования", "особые", "секретные", "сов.секр.", а в другой по их управленческой сути: приказы, уч.планы, ведомости и т.д., в третей - по важности: важню, к немедленному исполнению, забить пока гром не грянет и т.д. И в одной из этих иерархий преподавателям могут быть даны права на доступ, в числе прочих, к секр.док-ту. Например, док-т относится к уч.планам к которым преподы имеют доступ, но почему-то засекречен. Тогда группе преподы необходимо явно указать запрет. Тут-то всё и начинается. Избежать этого можно не используя перекрёстные группировки объектов, т.е. иерархия объектов должна быть единой, что, в свою очередь, снижает гибкость системы.

Приоритеты не нужны.
Вполне удачная схема была реализована MS, можно использовать ее.
Разве что можно усовершенствовать ее, задавая пользователю (администратору) устанавливать порядок ACL (админ имеет возможность выстроить запрещающие и разрешающие записи в произвольном порядке). Это несколько усложнит администрирование, но не настолько, как с приоритетами.

Собственно, я и имел в виду упорядочивание этих записей, но под утро уже не смог внятно это сформулировать. Опять-таки упорядочивать придётся не просто группы польз., а отношения группа польз - набор прав - группа объектов. В случае с пересекающимися группами объектов (см. выше) после установки прав группе объектов и упорядочивании ACL к ней, мы всё-равно не будем знать этот порядок для объектов принадлежащих одновременно нескольким группам. Снова тот же секр. уч. план: по версии "учебный" преподы стоят в начале списка и имеют допуск, а по версии "секретный" чекисты стоят раньше.

При объединении всё-равно получается неоднозначность. Нужно ещё определить какая из иерархий имеет больший вес, или приоритет, или стоит раньше (это одно и то же).

Код: Выделить всё

ACL "Секр. док-ты":
    Группа "чекисты" - да
    Группа "Преподы" - нет

ACL "Уч. планы":
    Группа "Преподы" - да
    Группа "чекисты" - нет

Док-т относится к обеим группам. Для самого док-та ACL явно не определены, а вычисляются исходя из его принадлежности к группе. Какими они будут и каков их порядок для пользователя входящего в группы "преподы" и "чекисты" одновременно? для пользователя входящего только в одну из групп?

Можно параллельно к ACL добавить еще два слоя -- роли и профили.

Можно подробнее? С примером. Т.к. роль можно рассматривать и как группу пользователей с определённым набором прав. Тут граница несколько расплывчатая. И с профилями тоже проясни, пожалуйста, примером.

Но лично я бы выбрал так, как это сделано в Windows (то, что предлагал GSerg во втором посте). Схема достаточно гибкая и в то же время не слишком сложная в использовании.

Файловая система - единая и жёсткая иерархия. В такой системе это работает на ура. Но стоит представить, что мы группируем док-ты не только по месту их расположения, а, скажем, ещё по автору, как она перестаёт быть простой. Кто-то имеет доступ к любым док-там Васи Пупкина, но не имеет к папке "компромат". В иерархии "автор" он имеет высший приоритет, т.к. является продюсером Васи Пупкина, а в иерархии "папки" его номер шестой. Давать ему доступ к компромату на Васю Пупкина или нет, если права даны не файлу, а физ. папке на диске и виртуальной папке "Вася Пупкин"? В аналогии с файловой системой можно, пожалуй, привести ссылки на файлы и папки. Если есть доступ к ссылкам, но нет к файлу, то доступа всё-равно нет, но если есть доступ к самим файлам, то не важно есть ли доступ к ссылкам на них. Только как и все аналогии эта тоже немного кривая, потому что ссылка всегда является производной от файла, а в случае произвольных и равноправных множественных иерархий объектов нельзя заранее сказать что в той или другой иерархии мы назначим собственно файлом, а что его ссылкой. И для разных иерархий это назначение может быть разным.

Если кто-нибудь понял чего-гибудь из этого потока сознания просто кивните. Спа-а-а-ать хочу, аж челюсти сводит.

Не хочу быть настырным, но выстраивание записей в произвольном порядке всего лишь задает строчке n приоритет 2^n не больше.

Согласен.

Установка приоритетов "ручками" дает большую гибкость.

Не понятно чему в твоём исполнении давать приоритеты. Или у меня уже котелок совсем не варит.

[GAGArin]

Док-т относится к обеим группам. Для самого док-та ACL явно не определены, а вычисляются исходя из его принадлежности к группе. Какими они будут и каков их порядок для пользователя входящего в группы "преподы" и "чекисты" одновременно? для пользователя входящего только в одну из групп?

В таком случае помимо иерархии пользователей должна быть иерархия док-ов. Т.е. если "Секретные док-ты" выше по приоретету чем "Учебные планы" доступ получат чекисты, и не получат преподы. Если в "Секретных документах" не сказано, что преподам доступ закрыть, то по "Учебным планам" он появиться и у них.

Т.е. выстраиваем сначала группы документов, а уже вторым уровнем в них выстраиваем группы пользователей. Или наоборот (тут уж как удобнее)

[alibek]

Допустим, имеется "плоская" куча, в которой храняться документы (без иерархии, без пути, без наименований, просто файлы с неким уникальным буквенно-цифровым названием, хоть GUID).
Для того, чтобы эти файлы отображать в удобном для человека виде имеется две таблички, одна FILE_ATTRIBUTES, которая для каждого файла указывает такую информацию, как имя файла, тип файла, размер, дата создания, автор, менеджер, отдел и прочее. Вторая табличка будет VIEWS, это представления -- иерархическая структура, реализующая требуемую организацию и распределение документов. Структура у нее довольно сложная, поэтому опишу подробнее. Во-первых, имеются поля ID, ParentID, Name, позволяющие выстраивать требуемую иерархию. Во-вторых, нужно реализовать возможность автоматической группировки по указанному набору полей. Например, есть представление \Приказы\АСУ, внутри которого должны автоматически создаваться подкаталоги типа 2005 (2005\01, 2005\02, ...), 2006 (2006\01, 2006\02), в зависимости от того, за какую дату имеются файлы в этом представлении. Есть также табличка VIEW_FILES, в которой определяются, в каком представлении отображать какие файлы.
Доступ к файлам можно обеспечивать исключительно по представлениям, можно также сделать доступ персонально по файлам, но это усложнит задачу, лучше ограничиться только представлениями.

Итак, имеется такая информационная структура:


Файлы и их атрибуты (таблички FILES, FILE_ATTRIBUTES):
ID: Name (Types) Author - Dep.1 - Dep.2 - Dep.3
0001: Доклад Иванова (doc) Иванов - лаборатория - кафедра
0002: Приказ №002 (doc) Петров - дирекция - администрация
0003: Результаты опытов (xls) Сидоров - лаборатория
0004: Приказ №003 (doc) Петров - дирекция - администрация - кафедра
0005: Объяснительная Сидорова (doc) Сидоров - лаборатория
0006: Доклад по Сидорову (doc) Васечкин - 2-й отдел - дирекция
0007: Приказ №004 (doc) Петров - дирекция - лаборатория

Т.е. имеем 7 файлов.

Имеется также следующая организационная структура (VIEWS):
ID - ParentID - Name
1 - - По типам
2 - - По департаментам
3 - - По категориям
4 - 1 - Приказы
5 - 1 - Доклады
6 - 1 - Объяснительные
7 - 2 - Дирекция
8 - 2 - Администрация
9 - 2 - Кафедра
10 - 2 - Лаборатория
11 - 2 - Безопасность
12 - 3 - Информационные материалы
13 - 3 - Административные документы
14 - 3 - Безопасность
15 - 12 - Доклады
16 - 12 - Результаты
17 - 13 - Приказы
18 - 13 - Объявления
Или, в виде дерева:

Код: Выделить всё

По типам (1)
  Приказы (4)
    *автоматическая группировка по департаментам, году и месяцу*
  Доклады (5)
    *автоматическая группировка по департаментам, сортировка по дате*
  Объяснительные (6)
    *автоматическая группировка по году и месяцу*
По департаментам (2)
  Дирекция (7)
  Администрация (8)
  Кафедра (9)
  Лаборатория (10)
  Безопасность (11)
По категориям (3)
  Информационные материалы (12)
    Доклады (15)
    Результаты (16)
  Административные документы (13)
    Приказы (17)
    Объявления (18)
  Безопасность (14)


И имеется такое распределение файлов по представлениям (VIEW_FILES):
ViewID - FileID [, FileID, ...]
4 - 0002, 0004, 0007
5 - 0001, 0003
6 - 0005
7 - 0002, 0004, 0007
8 - 0002
9 - 0001, 0004
10 - 0003, 0005
11 - 0006, 0007
12 - 0001, 0003
13 - 0002, 0004, 0005, 0007
14 - 0006
15 - 0001
16 - 0003
17 - 0002, 0004, 0007
18 -

Теперь разграничим права.
В принципе, уже сейчас достаточно обычной (типа Windows) безопасности, каждый пользователь будет иметь доступ к своим разделам, а файлы могут входить в разные разделы.
Но мы простых путей не ищем.

Предполагаю, что имеются таблички USERS и GROUPS, причем в GROUPS уже заведены системные группы (All, Guests и т.п.).

Итак, имеется табличка ACES (ID - G/D - AccessID - GroupID - UserID - ViewID - FileID), где G/D - разрешающий или запрещающий флаг, AccessID - ключ на тип доступа (доступ вообще, просмотр, изменение, удаление и т.п.), GroupID - ключ на группу, UserID - ключ на пользователя, ViewID - ключ на представление, FileID - ключ на файл. Указывается либо GroupID, либо UserID, но не оба поля вместе, тоже относится к ViewID/FileID. Тут надо определиться, что будет иметь больший приоритет, GroupID/UserID и ViewID/FileID. Предлагаю, что UserID имеет более высокий приоритет, чем GroupID, а FileID более высокий приоритет, чем ViewID.
Также имеется табличка ACLS (ID, Order, ACE_ID), списки, в которых определены различные разрешения на пользователя/группу.
Тут, кстати, от задачи многое зависит. Возможно GroupID/UserID лучше вынести в ACLS или вообще в отдельную табличку.
Также надо решить, будут ли наследоваться разрешения на представление с родительского представления.

Теперь заводим табличку ROLES (ID, ViewID, UserID, GroupID), в которой будет определяться, к какой группе GroupID относить пользователя UserID, если он находится в представлении ViewID. Т.е., например, пользователь Васечкин в представлении "Приказы" входит в группу "Преподаватели", а в представлении "Безопасность" - в группу "Информаторы".
Если система планируется масштабная, то будет довольно сложно управляться со всеми этими ролями. В этом случае поле UserID из таблички ROLES мы выносим в табличку PROFILES (ID, UserID, RoleID), в которой задаются типовые профили на каждого пользователя.
Вроде бы все.


Вот только все это реализовать без глюков будет большой головной болью, может лучше обойтись более простой схемой?

[GAGArin]

Ну и еще пару слов о реализации приоритетов и моей нелюбви к построчному разрешению/запрещению.

Пример будет базироваться на доступе пользователей к одному конкретному документу.

Группы: Все, Чекисты, Преподы, Неблагонадежные.
Доступ нужен всем кроме неблагонадежных преподов. Если они не чекисты.

Решение построчно отсутствует. Решение установкой приоритетов:

Все +2
Преподы -1
Неблагонадежные -1
Чекисты +1
(0 и меньше - доступ закрыт)

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

Для каждой группы документов набор правил свой. По выводу результатов для документов представленных в нескольких группах есть два пути:

Или расставлять абсолютные приоритеты групп документов т.е. Решение о даче/не даче доступа по группе "Секретные документы" всегда важнее аналогичного решения по группе "Учебные планы"

Или просто собирать все условия из всех групп в которых представлен документ и считать "итого" дать или не дать доступ. Это опять же позволит тоньше настроить условия доступа, но очень затруднит работу того несчастного, который будет эти приоритеты выставлять. Тут уже зависит от задачи.

[skiperski]

В принципе, уже сейчас достаточно обычной (типа Windows) безопасности, каждый пользователь будет иметь доступ к своим разделам, а файлы могут входить в разные разделы.

Вот он, камень преткновения! У тебя категории не пересекаются. Поэтому и получается всё разрулить. Например, "Приказы" у тебя это две независимые группы 4 и 17. При такой архитектуре вопросов не возникает. (Хотя, возникают, см. абзац ниже) Вот если группа "Приказы" в одном единственном числе и входит одновременно в группу 1 и 13, тогда - пипец. Как в твоём случае при описании док-та распределять его по группам? В приказы-4 включить, а в приказы-17 - нет? Или включить в обе группы? А если надо в обе, а пользователь забудет, не заметит, не знает о других группах? А появилась ещё одна описательная структура (ещё один VIEW) куда приказы тоже входят, но т.к. группы не пересекаются, то у документа не будет признака принадлежности этой новой группе? Можно реализовать механизм синонимов, т.е. "Приказы" как бы существуют в единственном числе при оформлении док-та, а на самом деле программно разносятся по разным группам. Пожалуй, это будет легче реализовать, чем мукаться с неочевидным объединением прав.

Кстати, каким будет решение для документа 0002, если к категориям 4, 7, 13 доступ разрешён, а к категориям 8 и 17 - запрещён? Номера категорий взял на вскидку.

[Ennor]

skiperski, ты хочешь невозможного - разграничение доступа не на уровне множеств, а на уровне конкретных членов этих множеств.

В Оракле, начиная с версии 8i, появилась такая вещь, как Row Label Security. В MSSQL 2005 тоже появилось что-то аналогичное, как называется не помню. Так или иначе, суть одна - права доступа на конкретную запись в таблице, а не на всю таблицу сразу.
За внутреннюю реализацию, сам понимаешь, не скажу, ибо не знаю, но для реализации такой схемы в общем случае потребуется изрядный system overhead, не находишь? Однако все это уже есть - пожалуйста, юзайте на здоровье.

Я у себя недавно реализовывал подобное, но у меня было 2 облегчающих фактора - приоритет разрешений над запрещениями и группирующий критерий. Т.е. я так или иначе все равно находил способ обрабатывать записи как единое множество на основе масочных правил. А в твоем случае этого, как я понимаю, нет. Значит, судьба у твоих админов такая - декартовы произведения разгребать.

[Ennor]

Если все еще интересно: в рекапе за март наткнулся на статейку о том, как RLS/CLS реализуется в MS SQL Server 2005. Сам не читал, но кому-нибудь может пригодиться...