Система ролей и разрешений не-RBAC: роль со свойствами

Question

В настоящее время мы проектируем a Система ролей и разрешений пользователей в нашем веб-приложении (ASP.NET), и, похоже, у нас есть несколько случаев , которые не подходит в рамках классического управления доступом на основе ролей (RBAC) . Я опубликую несколько вопросов, каждый из которых посвящен конкретному делу. Это мой второй вопрос (первый вопрос здесь: Система ролей и разрешений, не связанных с RBAC: проверка города пользователя ).

У нас есть следующий случай: нам нужно реализовать роль менеджера в нашем веб-приложении. Однако менеджер может принадлежать одной или нескольким компаниям (в рамках большой группы компаний, для которой мы создаем это веб-приложение). Скажем, может быть «Менеджер компаний А и Б», «Менеджер компании С» и т. Д.

В зависимости от компаний, к которым принадлежит Управляющий, он имеет доступ к определенным операциям: например, он может общаться с клиентами только тех компаний, к которым он принадлежит. То есть «менеджер компаний A и B» может иметь контакты только с клиентами компаний A и B, но не с клиентами компании C. Он также может просматривать страницы с подробной информацией клиентов компаний A и B, но не C и т. Д. .

Похоже, что это дело относится к RBAC. Однако это не совсем так. Нам нужно будет создать класс ManagerRole , который будет иметь свойство Companies - то есть это будет не просто роль в качестве набора разрешений (как в классическом RBAC), но роль со свойствами !

Это был только один пример роли, обладающей свойствами. Существуют и другие: например, роль администратора , которая также будет принадлежать ряду компаний, а также будет иметь другие настраиваемые свойства.

Это означает, что у нас будет иерархия или роли классов:

class Role – base class  
class ManagerRole : Role  
    List Companies  
class AdministratorRole : Role  
    List Companies  
    Other properties

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

Мы могли бы моделировать наши дела, используя разрешение со свойствами , такими как ManagerPermission, AdministratorPermission, но у этого есть много недостатков, главным из которых является то, что мы не сможем назначить роль типа «Менеджер компаний» A и B ”непосредственно для пользователя, но ему придется создать роль, содержащую ManagerPermission для компаний A и B… Более того,« Менеджер », скорее, скорее« роль »(должность в компании), чем« разрешение » с лингвистической точки зрения.

Буду признателен за любые идеи на эту тему, а также за любой опыт в этой области!

Спасибо.

Answer 1

В настоящее время я пытаюсь реализовать свою собственную версию библиотеки RBAC (по простым причинам, когда нужно изучать внутренности RBAC, настраивая ее специально для моей базы кода / базы данных). (Примечание: ограничения - самая сложная часть) !!

То, как я справился с этим (еще не полностью реализованным), заключается в том, что я создал группы, которые в основном представляют собой совокупность пользователей. Так что в этом случае я бы создал три группы; Компания A, Компания B и Компания C, а затем назначить каждого пользователя соответствующим группам (компаниям).

Затем вы можете назначить роль диспетчера конкретным пользователям, а группам также могут быть назначены роли. Мне это нравится, потому что это позволяет мне добавлять один ролик ко многим пользователям одновременно (очень, очень быстро во время транзакций с БД, и после кэширования объем памяти значительно уменьшается).

Итак, в вашем примере, скажем, у вас есть модель учреждения (или экземпляр объекта), которая отображается в вашем пользовательском интерфейсе. Просто щелкнув по нему, а затем выбрав для него меню «Безопасность», вы получите окно, в которое можно добавлять пользователей / членов группы (например, безопасность Windowns). Добавляя (группируя) компанию A и предоставляя разрешения на «чтение», вы, по сути, разрешаете всем пользователям в этой группе доступ на чтение к этой компании и ее дочернему объекту, которые будут контактами клиентов и тысячами других экземпляров модели.

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

Answer 2

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

Вы хотите добавить дополнительный уровень произвольной дискриминации к основной роли.

Чтобы реализовать подобный RBAC и сохранить возможность использовать преимущества любой встроенной инфраструктуры, вам нужно будет пойти на несколько компромиссов и создать несколько пользовательских реализаций.

Первый шаг - это компромисс принятия соглашения об определении роли. например когда вы хотите определить, находится ли пользователь в роли «менеджер» компании «companyA», вы определяете правило, будь то атрибут, код или, возможно, карты сайта, как «manager-companyA», т.е. IsUserInRole("manager-companyA").

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

Вам потребуется как минимум реализовать методы, используемые ASP.Net, чтобы убедиться, что роли проверены или выведены в правильном формате.

IsUserInRole получит строку, которую вам придется, используя соглашение, проанализировать в составные сегменты для проверки, как описано ранее.

GetRolesForUser может вызываться при кэшировании ролей в файлах cookie и должен выполнять иерархическую рекурсию ролей и выводить все перестановки. например Пользователь является менеджером для companyA и companyB, поэтому GetRolesForUser("user") должен вернуть массив, состоящий из значений manager-companyA и manager-companyB, для использования инфраструктурой asp.net, которая использует кэшированные роли и не выполняет интерактивный опрос RoleProvider.

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

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

Answer 3

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

http://www.tonymarston.net/php-mysql/role-based-access-control.html (см. Раздел «Другие типы контроля доступа» внизу страницы)

Опять же, я не уверен, что это то, что вы ищете или нет, но это может стоить быстрого просмотра.

Answer 4

Если ваша проблема будет решена путем реализации наследования для ролей, вы можете реализовать это.

Ваш пример - еще одна возможность пойти по пути управления доступом на основе атрибутов (например, разрешить пользователю, который играет роль менеджера И работает в компании А). Однако реализовать систему RBAC гораздо сложнее.