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

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

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

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

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

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

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

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

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

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

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

• AddUsersToRoles
• RemoveUsersFromRoles

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

• DeleteRole
• CreateRole

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

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

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

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

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