Как мы можем использовать безопасность на основе ролей в динамичной среде? - PullRequest
0 голосов
/ 23 августа 2011

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

AddProduct, RemoveProduct, EditProduct, AcceptPurchase, DenayPurchase, ...

Таким образом, для средней системыу нас должно быть как минимум 50 ролей!Тогда как администратор может назначить эти роли каждому пользователю?

У нас есть два решения на первый взгляд:

  1. Создать таблицу в БД (например, Группу ) ставить между пользователями и ролями.Затем администратор должен создать группу ролей, а затем назначить группу нескольким пользователям.

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

Мы вскоре обнаружим бессмысленность первого подхода.И мы реализуем несколько проектов со вторым подходом.Но теперь мы хотим использовать его в проекте sivlerlight помимо сервисов аутентификации RIA WCF.Он просто поддерживает роли.Например, каждый пользовательский экземпляр имеет метод IsInRole , который мы реализуем вместо этого наш метод IsInPermission .

Существует другая проблема при использовании атрибута requireRole дляСервисы.Я не могу и не хочу ставить имя роли жесткого кода для каждого метода службы.

Знайте, что мы так запутались в дизайне безопасности на основе ролей!Как мы можем использовать его в таких ситуациях?

1 Ответ

2 голосов
/ 23 августа 2011

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

Например, в парадигме авторизации на основе ролей ASP.NET, которую выИспользуемые сейчас фактические «роли» соответствуют фиксированному (то есть известному во время компиляции) набору операций.Например, вместо гранулярных разрешений «AddProduct», «RemoveProduct» и «EditProduct», указанных в исходном сообщении, можно ожидать фиксированную роль «Product Manager».Если вы хотите авторизоваться на более детальном уровне, тогда этот «чистый» ролевый подход не очень подходит, и IPrincipal.IsInRole, вероятно, совсем не то, что вам следует использовать.

Звучиткак вы хотите авторизовать гранулированные «операции», с операциями, сгруппированными в «роли» через конфигурацию времени выполнения.Некоторый набор «административных» пользователей будет иметь разрешения для управления этой конфигурацией.Они могут создавать, изменять и удалять «роли» по своему усмотрению, причем каждая «роль» представляет собой набор «операций», которые распознаются вашим приложением (т. Е. «Роль» означает «операция», а «группа» - это »).пользователь ").Ваше приложение не должно быть осведомлено о ролях.Вместо этого он будет разрешать операции.Пользователям будут предоставлены разрешения на операции с помощью любого из следующих действий:

  1. Предоставление пользователю разрешения на операцию,
  2. Предоставление разрешения на операцию группе, к которой принадлежит пользователь,
  3. Предоставление разрешения роли пользователю или
  4. Предоставление разрешения роли группе, к которой принадлежит пользователь.

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

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

...