Кросс-пост с RSDN
Классическая rbs (role-based security)
Есть Роли, Пользователи могут иметь несколько ролей, Роли имеют несколько Разрешений.
То есть между Пользователями и Ролями связь многие-ко-многим, и между Ролями и Разрешениями многие-ко-многим.
Такая модель эффективна для небольших приложений, где роли определены и зачастую совпадают с ролями в процессе, а разрешения выдаются на некоторые действия.
Фактически Роль определяет как группу пользователей, так и что они могут делать.
Настраиваемая RBS
Тут роли разделяются на группы пользователей и наборы разрешений. Пользователи связаны многие-ко-многим с группами, группы — многие-ко-многим с наборами разрешений, наборы разрешений — многие-ко-многим разрешениями.
Разрешения также выдаются на некоторые действия, но при большом количестве удобнее управлять согласованными наборами разрешений, а не отдельными разрешениями. Наборы разрешений можно изменять в процессе работы программы, как и группы пользователей.
По опыту такая система сложнее классической раз в пять. Поэтому без необходимости городить не стоит.
Claims-based security
Почти тоже самое что и предыдущий пункт, только вместо групп пользователей используются claim_ы которые могу иметь разный тип (имеется ввиду бизнес-тип). Типичные claims - это имя пользователя, группы (может быть несколько), email, в бизнес-приложениях это также может быть имя менеджера, отдел итп.
Таким образом пользователи имеет много claim_ов, каждый claim определяется парой (тип, значение), набор разрешений привязывается к набору claim_ов.
А теперь самое интересное. Система разграничения прав в приложениях с CBS часто оказывается проще, чем RBS в настраиваемом вида. RBS заставляет плодить много групп, в том числе автоматически. При использовании CBS от этого можно совсем отказаться, а сам механизм получения claim_ов вынести отдельно, что уменьшит сложность самого приложения (например Windows Identity Foundation так и работает, и позволяет сделать claims-provider, работающий с AD).
Кроме того возможен fallback к RBS — достаточно один из типов claim_ов объявить группой\ролью.
Это неполный список, всегда можно придумать вариации.
Все выше касалось ограничения на выполнение функций системы, теперь мы хотим защищать доступ к объектам в системе.
Поначалу все просто : связь роль-разрешения, группа-группа разрешений, набор claim_ов — группа разрешений становится тренарной, то есть к каждой связи добавляет атрибут — ссылка на объект. Тогда сама связь, указывающая что для данного объекта данная роль имеет указанные разрешения становится неким ACE (Access Control Entry из терминологии Windows), множество ACE, сгруппированных по ссылке на объект, называются ACL (Access Control List).
Вроде все просто, но при построении такой системы надо решить несколько принципиальных вопросов:
- Вычисление "эффективных разрешений". При наличии иерархии защищаемых объектов надо уметь однозначно получать разрешения которые действуют для данного объекта, с учетом разрешений вышестоящих объектов. Прием если связи между объектами имеют циклы, то однозначность становится проблемой.
- Владение объектом. Зачастую при вычислении возможности доступа нужно учитывать кто создал этот объект и как авторство объекта влияет на эффективные разрешения.
- Как с учетом вышесказанного сделать чтобы это быстро работало. Проверка разрешений и так усложняет выборки данных, а если еще требуется вычислять эффективные разрешения с учетом иерархии, то это может очень сильно сказаться на производительности.
Часто такую систему называют Row-Level Securty, потому что проверки реализуются на уровне строк БД, иначе очень медленно будет.
