Разрешения / правильная модель / шаблон для приложения .NET

9

Мне нужно реализовать гибкий И простой (если такая вещь существует) и в то же время использовать встроенные средства, если это возможно

До сих пор я реализовал MembershipProvider и RoleProviders. Это круто, но куда мне идти дальше?

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

Это звучит как хорошая модель? Стоит ли думать о добавлении привилегий на уровне пользователя поверх добавления их в роли? Я мог бы, но я представляю проблемы с настройкой (путаница) и после поддержки.

Если я этого не сделаю, и некоторым конкретным пользователям понадобятся меньшие привилегии - администратору придется создать другую роль и т. Д.

Любая серебряная пуля для такой системы? И почему Microsoft не пошла дальше, чем просто провайдеры членства и ролей?

Еще одна идея: оставить роли в качестве держателя привилегий и жестко их кодировать. Затем я могу кодировать эти роли внутри приложения, используя все доступные пометки / атрибуты и т. Д. - все Microsoft.

Добавить новую сущность "Группа" и создать отношения, как это

  • пользователей
  • USERGROUPS
  • группы
  • RoleGroups
  • Роли

Таким образом, я могу собирать роли в группы и назначать эти группы пользователям. Звучит отлично и соответствует другим программным паттернам. Но тогда я не могу реализовать такие вещи внутри RoleProvider, как:

  • AddUsersToRoles
  • RemoveUsersFromRoles

И некоторые вещи больше не имеют смысла, потому что они будут жестко закодированы

  • DeleteRole
  • CreateRole
катит
источник

Ответы:

5

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

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

В этой модели утверждение эквивалентно тому, что вы называете «привилегией», и вы группируете утверждения в наборы утверждений, что примерно эквивалентно тому, что вы называете «ролью». Все эти API и многое другое уже находятся в System.IdentityModelпространстве имен.

Конечно, вы упоминаете, MembershipProviderи RoleProviderесли вы пытаетесь втиснуть все это в модель членства ASP.NET (как и подразумевают эти имена), то просто забудьте об этом. Если вы хотите использовать эти API-интерфейсы провайдера, то вы должны сделать это по-своему, и их путь не становится более детальным, чем концепция роли.

Вместо этого в ASP.NET понятие «привилегия» фактически кодируется на уровне действия или операции , где вы объявляете, каким ролям разрешено выполнять это действие. Это действительно намного проще в ASP.NET MVC, где вы просто нажимаете [AuthorizeAttribute]на контроллеры или действия контроллеров; в «старой школе» ASP.NET вы обрабатываете события, поэтому авторизация может быть либо произвольной, либо на уровне страницы (или обеих).

Aaronaught
источник
Много отличной информации, спасибо! Приложение на самом деле является приложением Silverlight с частью сервера, предоставляемой в качестве службы WCF RESTful. На основе утверждений выглядит интересно, но я не заметил концепции пользователя и авторизации внутри него. Интересная статья, которую я только что нашел: geekswithblogs.net/shahed/archive/2010/02/05/137795.aspx
катит
@katit: практически вся аутентификация / авторизация в .NET основана на интерфейсе IPrincipal . Если вы делаете авторизацию на основе утверждений , то вы используете IClaimsPrincipal для этого, и бросили IPrincipalв , IClaimsPrincipalкогда вы хотите сделать исковые чеки. Вы будете писать большую часть своего собственного кода, если вы хотите, чтобы он соответствовал (например) Аутентификации с помощью форм, но, очевидно, это можно сделать (согласно ссылке).
Аарона
вопрос в том ... Может быть, проще просто добавить еще один "групповой" уровень к поставщикам членства / роли или написать собственного поставщика? Практически такой же объем работы, как и в реализации Microsoft
катит
3
@katit: Известные последние слова. Не изобретайте свое собственное, если у вас нет очень веской причины изобретать свое собственное («это кажется проще» - не веская причина; это кажется легче, когда у вас нет прямого опыта и, следовательно, у вас нет возможности судить о объем работы требуется).
Аарона