Не могли бы подкинуть статей, что почитать на эту тему?

Как должна быть организована зависимость между этим сущностями "пользователь", "роль", "право" в общем случае?
Какой из подходов более верный (опять же в общем случае):
1)Пользователь содержит данные о том, какие роли ему назначены. Роли содержат данные о том, какие права они собой представляют.
2)Пользователь содержит данные о том, какие роли ему назначены. Права содержат данные о том, в какие роли они включены.

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

Здравствуйте, Donz, Вы писали:

D>Не могли бы подкинуть статей, что почитать на эту тему?

D>Как должна быть организована зависимость между этим сущностями "пользователь", "роль", "право" в общем случае?
D>Какой из подходов более верный (опять же в общем случае):
D>1)Пользователь содержит данные о том, какие роли ему назначены. Роли содержат данные о том, какие права они собой представляют.
D>2)Пользователь содержит данные о том, какие роли ему назначены. Права содержат данные о том, в какие роли они включены.

D>Своя точка зрения присутствует, но пока писать ее не буду. Хотелось бы услышать аргументированные "за" и "против" или вообще третий вариант зависимостей между этими сущностями.

Вобщем-то разницы никакой — все равно нужно получить набор прав пользователя в итоге. Роли\группы в данном раскладе как бы только для удобства. Но второй вариант все таки странен — напиши код получения прав пользователя и посмотри как оно получается. Но повторюсь — по большому счету разницы нет — ибо само отношение между сущностями инвариант в обоих схемах.

Многие ко многим

Может конеш религия — тем не менее: дерево групп/ролей + многие-ко-многим между пользователями и группами.

С одной стороны достаточно гибко, с другой — не даёт создать эдакую "паучью сеть" когда непонятно кто от кого и как получает разрешения. Плюс явно виден порядок распространения разрешений.

Дальше. Не стоит заводить "право" вообще — замучаетесь. Выделите вместо этого отдельные области в которых будете рулить разрешениями (чаще всего это будут отдельные подсистемы/модули). В этих областях определите атомарные действия — типа "создать сущность a, изменить сущность b" и т.п.
Сопоставьте каждому атомарному действию битовый флаг. Дальше определите пресеты — наборы битовых операций, которые определяют допустимые операции для каждого разрешения. Если пресет небольшой — представьте в виде инта. И собсно напоследок — назначение разрешений: пара id пользователя/группы — пресет.

В результате разрешения считаются при помощи элементарных битовых операций.

Интересует что конкретное/предложения/возражения — вэлкам

Здравствуйте, Donz

Пользователю назначается роль.
Ролям назначаются права.
Каждому пользователю можно менять роль и список прав.

Здравствуйте, VGn, Вы писали:

VGn>Многие ко многим

Ответ "42" был бы короче и смешнее.

Здравствуйте, Sinix, Вы писали:

Спасибо за подробное объяснение, но тут скорее интересует архитектура, чем конкретное техническое решение. Битовые маски будут использоваться в любом случае. От "прав" уже не деться, да и не вижу причин от них отказываться. Если что, я под "правом" понимаю некое атомарное действие, на которое у пользователя либо есть право выполнения, либо нет. Можно сказать, это объект с двумя возможными типами доступа: "можно все", "нельзя ничего".

[skip]
S>Сопоставьте каждому атомарному действию битовый флаг. Дальше определите пресеты — наборы битовых операций, которые определяют допустимые операции для каждого разрешения. Если пресет небольшой — представьте в виде инта. И собсно напоследок — назначение разрешений: пара id пользователя/группы — пресет.

Имеется в виду, что пользователь может быть включен в несколько групп плюс у него могут быть отдельные установки на конкретные права (то бишь, пресет)?
Можно сказать, это основной вопрос. На данный момент в проекте преполагается, что назначение отдельных прав конкретному пользователю невозможно, и все права раздаются только через роли. У меня есть большие сомнения, что не появится исключений, при которых одними ролями не обойтись, а создавать новую роль, которую будут видеть все (пользователей очень много), ради одного пользователя нелогично.
Если назначение конкретного права пользователю все-таки понадобится, то при первом подходе из начального поста нужно будет дополнить структуру только пользователя. Сами "права" как не знали о том, кто их может использовать, так и далее не будут знать, то есть достигается некоторый уровень абстракции.
При втором подходе придется изменять структуру как пользователей, так и прав. Насколько я понял, аргумент в пользу этого метода заключается в том, что объект "право" будет содержать данные о всех субъектах (ролях), которые к нему имеют доступ. Правда, при прямом назначении права пользователю непонятно, как это красиво сделать. И конкретно мне непонятно, зачем нужно хранить данные о субъектах в объекте, когда объектов мало, и они навряд ли будут меняться, а субъектов очень много, при этом они постоянно изменяются в случае с пользователем и могут редко меняться в случае с ролями.

D>Ответ "42" был бы короче и смешнее.

«Чтобы правильно задать вопрос, ты уже должен знать большую часть ответа» — Роберт Шекли

Здравствуйте, Donz!

Хотите архитектуру-говорим только о ней, сорри

у вас право в себе объединяет две независимые сущности — действие и тип разрешения. Сейчас у вас только 2 состояния — можно все", "нельзя ничего". Что будет, если вам потребуется состояние "может делегироваться другому"? Можно конеш добавить ещё битиков. А "наследовать на n уровней вниз"? Так что нефиг смешивать Гораздо лучше завести отдельно действия и отдельно списки разрешаемых действий, списки наследуемых действий и т.п. Всё равно наследование этих разрешений должно производиться отдельно, а вычисление результирующего разрешения — в самом конце. Понадобится новый тип обработки равзрешений — заведёте новый список и добавите в него те же самые действия, только и всего.

// мы всё ещё говорим об архитектуре — список действий вполне может превратиться в битовую строку

Теперь про группы. У вас опять идёт смешивание 2 механизмов — назначения разрешений и управления пользователями. В результате вы огребётесь при малейшем изменении требований. Разделите задачи:
1) Для администратора у вас есть пользователи и группы.
2) Для разруливания разрешений — список принципалов текущего пользователя (принципал — общий термин для объектов, которым даются разрешения) и список назначенных разрешений, что содержит кортеж
{id принципала,id объекта,пресет разрешённых действий,пресет запрещённых действий...}.
3) Ограничение типов принципалов должно решаться при назначении разрешений(в идеале дублируется constraint'ом в базе).

Могу предложить корявоизящный вариант: id пользователей -нечётные, групп — чётные. Дальше делаете ограничения — в список разрешений A могут добавляться только принципалы с чётными идентификаторами. В список B — все кто угодно и т.п. // упс, опять меня в реализацию понесло

Напоследок: никакие изменения в вычислении/назначении разрешений не должны влиять на способ описания пользователей/групп. Это разные системы.

Если недоответил/что-то упустил — пинайте, исправлюсь

Здравствуйте, Sinix, Вы писали:

[skip]
К сожалению, с архитектурой уже все решилось — количество победило, потому второй вариант из первого поста.
Спасибо за развернутый ответ, правда, у меня очень упрощенная схема, и половину описанного навряд ли стоит воротить, но на будущее буду знать.

S>Теперь про группы. У вас опять идёт смешивание 2 механизмов — назначения разрешений и управления пользователями. В результате вы огребётесь при малейшем изменении требований. Разделите задачи:
S>1) Для администратора у вас есть пользователи и группы.
S>2) Для разруливания разрешений — список принципалов текущего пользователя (принципал — общий термин для объектов, которым даются разрешения) и список назначенных разрешений, что содержит кортеж
S>{id принципала,id объекта,пресет разрешённых действий,пресет запрещённых действий...}.

Я так понимаю, тут под id объекта понимается идентификатор субъекта (пользователь, роль и т.д.)? Если принципал — это и есть объект, то зачем еще один объект?
В конечном итоге это называется ACL, правильно?

Мы ввели абстракцию, которой принадлежат права — SID.
В Hibernate соответственно User.getSid().getPermissions() и Role.getSid().getPermissions(), в базе — таблица SID с OWNER_ID без FK.

Здравствуйте, Donz, Вы писали:

D>Здравствуйте, Sinix, Вы писали:

D>[skip]
D>К сожалению, с архитектурой уже все решилось — количество победило, потому второй вариант из первого поста.
D>Спасибо за развернутый ответ, правда, у меня очень упрощенная схема, и половину описанного навряд ли стоит воротить, но на будущее буду знать.

Сочуствую или не сочуствую — не зная что вам надо на самом деле — не скажу. То что я описал совсем не сложная штука, она страшно смотрится только на словах.
ID — да, идентификатор объекта. Поскольку для определения разрешений должно быть пофиг кто у нас — пользователь или группа, у нас должна быть общая идентификация. Способ реалиации — GUID/промежуточная сущность/сквозная идентификация — на ваше усмотрение. Я остановился на последнем. Принципал — чисто абстракция. Выглядит как-то так:

CREATE VIEW Security.UserPrincipals AS
BEGIN
  SELECT Security.CurrentUserID() AS Principal_ID, 1 AS IsUser
  UNION ALL
  SELECT G.ID, 0
    FROM Security.Groups G INNER JOIN Security.UserGroups UG
      ON G.ID = UG.Groups_ID
    WHERE UG.Users_ID = Security.CurrentUserID()
END

Дальше эта вьюха используется для разруливания разрешений. Чтобы получилось читабельно, вьюха не включает в выборку родительские группы — на самом деле их надо включать, или не будет наследования разрешений. Соответственно, добавляется столбец NestingLevel.

Если чуствительна производительность — пишется триггер на логин или job, который заранее вычисляет пользовательские идентификаторы и забивает их в служебную табличку. Наш view гребёт данные из той таблицы, а не считает их динамически.

D>В конечном итоге это называется ACL, правильно?
Не-не, вы зря относитесь с таким уважением к трём волшебным буковкам. Под определение ACL подходит и то что я написал, и ваш вариант, и подход informix'а (хотя я не пойму зачем вычислять на каждый чих _все_ разрешения — наверно так надо).

В моём варианте ACL — это табличка OrderPermissions с атрибутами {Principal_ID, Order_ID, AllowedActionsBitmask, DeniedActionsBitmask...}, причём будет один ACL на каждую область — для заказов, документиков и т.п. Вы ведь не хотите в одном списке держать разрешения на важные документы и на заполнение заявок на туалетную бумагу

ACL реально нужно только в сложных сценариях. Как правило я просто завожу хранимые процедуры, что выполняют примитивные действия и даю execute права на них ролям СУБД. Дальше добавляем пользователя в роль — вуаля, есть разрешения

Другими словами: ACL нужны для разруливания прав на уровне конкретных сущностей. Для ограничения доступа к системе пользуйтесь стандартными средствами — например безопасностью СУБД.

Здравствуйте, Donz, Вы писали:

D><skipped>

Интересно, что никто не предложил сделать анралог самой гибкой системы безопасности, которую я только знаю — Active Directory. Вкратце, идея такова — есть типы сущностей, доступ к которым надо контролировать (объекты авторизации), у каждого типа есть набор атомарных операций, которые можно произвести над типом. Ещё есть субъект авторизации (его обычно называют принципалом) — это юзер или группа. Соответственно, есть два варианта разрешений:
1. разрешение производить операцию над любым объектом данного типа.
2. разрешение производить операцию над конкретным объектом данного типа.
Логично первый тип разрешений хранить в составе принципала (пример — то, что в OS Windows называется привилегией), а второй — в качестве метаданных объекта (пример — Security Descriptor в файловой системе NTFS). Впрочем, раз уж вы просили воздержаться от обсуждения реализации, то не буду затрагивать этот момент

Здравствуйте, koandrew.

В принципе нечто подобное и описывал, правда не настолько абстрактно
1) проще реализовать силами СУБД — оно есть из коропки
2) — списки ACL + хранимки которые используют списки для фильтрации

Конеш можно написать всё и целиком с нуля, но это дичайший гемморой, особенно в плане сквозной авторизации/интеграции с внешними системами.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, koandrew.

S>В принципе нечто подобное и описывал, правда не настолько абстрактно
S>1) проще реализовать силами СУБД — оно есть из коропки
S>2) — списки ACL + хранимки которые используют списки для фильтрации

S>Конеш можно написать всё и целиком с нуля, но это дичайший гемморой, особенно в плане сквозной авторизации/интеграции с внешними системами.

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

А хранимки или не хранимки — это тема отдельной "беседы", не имеющей к архитектуре никакого отношения Вон в форуме .NET не утихают баталии на эту тему. Но всё же не удержусь и выскажу своё мнение — хранимки — это зло

Здравствуйте, koandrew!

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

2) про хранимые процедуры: а для чего вы их хотите использовать?
ХП удобны для инкапсуляции реальных структур данных и для реализации подхода "sql живёт только на сервере". View для этого использовать на порядок сложнее — допустим, в SQL Server'e без специальных приседаний OUTPUT clause не возвращает значения от insetad of триггера. Ну а давать клиенту прямой доступ к табличкам не всегда возможна. Что остаётся?

Ну и уже кучу раз сталкивался, что интеграция на уровне СУБД — полная фигня по сравнению с попыткой использования API чужих софтин. Чемпион — госовский модуль сбора данных, что требовал координаты комбобокса на его форме чтобы получить оттуда выбранное значение

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, koandrew!

S>1) про самописный контроль доступа: это реальнейшая попа в крайних ситуациях — например, когда требуется делегировать текущий контекст внешним системам. Тут уж проще использовать стандартные фичи из коробки. В остальном — согласен и поддерживаю.
Согласен, иногда это может вылиться в приличный гемор. Однако на практике мне приходилось решать только обратные задачи Ну и для делегации контекста можно (если можно) заюзать имперсонацию — это как бы тоже "из коробки" Вообще очень многие вещи упрощаются, если юзать AD-авторизацию

S>2) про хранимые процедуры: а для чего вы их хотите использовать?
S>ХП удобны для инкапсуляции реальных структур данных и для реализации подхода "sql живёт только на сервере". View для этого использовать на порядок сложнее — допустим, в SQL Server'e без специальных приседаний OUTPUT clause не возвращает значения от insetad of триггера. Ну а давать клиенту прямой доступ к табличкам не всегда возможна. Что остаётся?

Давайте не будем об этом тут? Если "хотите об этом поговорить" — создавайте отдельную тему — там поспорим. А тут оффтопить не стоит... Вкратце моя позиция по этому вопросу — интеграция на уровне БД — зло, я стараюсь использовать БД только как внутреннюю подсистему конкретного API, закрывая доступ в неё иначе как через него. Так проще масштабировать компоненты системы(stateless API vs stateful DB), да и интероп через веб-сервисы как средство интеграции мне импонирует гораздо больше (помимо всего прочего, они кроссплатформенны). Просто я обычно проектирую системы по принципу "чёрных ящиков" и минимизирую зависимости. При таком подходе чаще всего можно без проблем обойтись plain SQL, и, соответственно, не завязываться на конкретный сервер...

Здравствуйте, koandrew, Вы писали:

Действительно хватит. Завязываем

Здравствуйте, Donz, Вы писали:

D>Не могли бы подкинуть статей, что почитать на эту тему?
Есть цикл сообщений в блоге Ayende на эту тему: Rhino Security

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

D>>Не могли бы подкинуть статей, что почитать на эту тему?
A>Есть цикл сообщений в блоге Ayende на эту тему: Rhino Security
Странно, но исходное сообщение (которое дало старт проекту Rhino Security) не "затегено": A vision of enterprise platform: Security Infrastructure