Шаблоны / конструктивные предложения для обработки разрешений

Question

У нас довольно сложная система обработки разрешений в нашем приложении (ASP.NET web). Пользователи могут иметь определенные разрешения для различных типов объектов, некоторые разрешения даже упакованы в группы / роли, которые назначаются пользователям. В итоге все это приводит к довольно сложному беспорядку, когда для определения, может ли пользователь что-то делать / видеть, нужно оценить множество различных источников разрешений, и это делается как-то по требованию и в зависимости от конкретных ситуаций.

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

Answer 1

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

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

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

Answer 2

Пользователи и Группы с возможностью проверки bool UserHasPermission( SOME_PERMISSION ) для атомарного разрешения, связанного с Группой, является стандартным подходом к авторизации, однако ситуация меняется на основе утверждений:

http://msdn.microsoft.com/en-us/magazine/ee335707.aspx

http://msdn.microsoft.com/en-us/magazine/cc163366.aspx

http://www.infoq.com/news/2009/10/Guide-Claim-Based-Identity

Однако он не идеален для всех ситуаций.

Для старой модели я считаю, что производительность можно повысить с помощью запоминания во время проверки разрешений. Таким образом, я не собираюсь в базу данных n раз за сессию, чтобы проверить контроль доступа. Мемоизация эффективно сохраняет в кеше результат вызова с одинаковыми параметрами, поэтому все вызовы определенного пользователя для проверки разрешения XYZ будут возвращать один и тот же результат. Конечно, вы должны убедиться, что сохранили запомненные разрешения для пользователя в сеансе, так что это для каждого пользователя. Если вы загружаете разрешения при входе в систему, вам не нужно их кэшировать, но в больших системах с большим количеством разрешений иногда лучше получать их только при необходимости.

http://www.infoq.com/news/2007/01/CSharp-memory

Answer 3

Я не имел дело с этим с точки зрения разработки приложений, но часто при работе с разрешениями рекомендуется устанавливать разрешения для объектов с использованием ролей, а не давать пользователям разрешение непосредственно на объект. Если пользователю нужен доступ к определенному набору объектов, вы не предоставляете им доступ напрямую, вы вместо этого назначаете ему роль, которая, в свою очередь, имеет необходимый доступ. Это в некотором смысле «повторно» использует работу, которая была вложена в создание роли.

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