Созданное удостоверение может принадлежать одной или нескольким ролям. When an identity is created it may belong to one or more roles. Например, Траци может принадлежать администратору и ролям пользователей, пока Скотт может принадлежать только к роли пользователя. For example, Tracy may belong to the Administrator and User roles whilst Scott may only belong to the User role. Создание и управление этими ролями зависит от резервного хранилища процесса авторизации. How these roles are created and managed depends on the backing store of the authorization process. Роли предоставляются разработчику через метод IsInRole в классе ClaimsPrincipal . Roles are exposed to the developer through the IsInRole method on the ClaimsPrincipal class.
Содержание
Добавление проверок ролей Adding role checks
Проверки авторизации на основе ролей являются декларативными—разработчик внедряет их в код для контроллера или действия в пределах контроллера, указывая роли, членом которых должен являться текущий пользователь для доступа к запрошенному ресурсу. Role-based authorization checks are declarative—the developer embeds them within their code, against a controller or an action within a controller, specifying roles which the current user must be a member of to access the requested resource.
Например, следующий код ограничивает доступ к любым действиям в AdministrationController для пользователей, являющихся членами роли Administrator : For example, the following code limits access to any actions on the AdministrationController to users who are a member of the Administrator role:
Можно указать несколько ролей в виде списка с разделителями-запятыми: You can specify multiple roles as a comma separated list:
Этот контроллер будет доступен только пользователям, являющимся членами роли HRManager или роли Finance . This controller would be only accessible by users who are members of the HRManager role or the Finance role.
При применении нескольких атрибутов пользователь, обращающийся к, должен быть членом всех указанных ролей. в следующем примере необходимо, чтобы пользователь был членом роли PowerUser и ControlPanelUser . If you apply multiple attributes then an accessing user must be a member of all the roles specified; the following sample requires that a user must be a member of both the PowerUser and ControlPanelUser role.
Можно дополнительно ограничить доступ, применив дополнительные атрибуты авторизации роли на уровне действия. You can further limit access by applying additional role authorization attributes at the action level:
В предыдущем фрагменте кода члены роли Administrator или роли PowerUser могут получить доступ к контроллеру и действию SetTime , но только члены роли Administrator могут получить доступ к действию ShutDown . In the previous code snippet members of the Administrator role or the PowerUser role can access the controller and the SetTime action, but only members of the Administrator role can access the ShutDown action.
Можно также заблокировать контроллер, но разрешить доступ к отдельным действиям с анонимным доступом без проверки подлинности. You can also lock down a controller but allow anonymous, unauthenticated access to individual actions.
Для Razor Pages AuthorizeAttribute может применяться одним из следующих: For Razor Pages, the AuthorizeAttribute can be applied by either:
- С помощью соглашенияили Using a convention, or
- Применение AuthorizeAttribute к экземпляру PageModel : Applying the AuthorizeAttribute to the PageModel instance:
Атрибуты фильтра, включая AuthorizeAttribute , могут применяться только к PageModel и не могут применяться к конкретным методам обработчика страницы. Filter attributes, including AuthorizeAttribute , can only be applied to PageModel and cannot be applied to specific page handler methods.
Проверки ролей на основе политик Policy based role checks
Требования к ролям также можно выразить с помощью нового синтаксиса политики, при котором разработчик регистрирует политику при запуске как часть конфигурации службы авторизации. Role requirements can also be expressed using the new Policy syntax, where a developer registers a policy at startup as part of the Authorization service configuration. Обычно это происходит в ConfigureServices() файле Startup.CS . This normally occurs in ConfigureServices() in your Startup.cs file.
Политики применяются с помощью свойства Policy атрибута AuthorizeAttribute . Policies are applied using the Policy property on the AuthorizeAttribute attribute:
Если необходимо указать несколько допустимых ролей в требовании, то их можно указать в качестве параметров метода RequireRole : If you want to specify multiple allowed roles in a requirement then you can specify them as parameters to the RequireRole method:
В этом примере разрешаются пользователи, принадлежащие к ролям Administrator , PowerUser или BackupAdministrator . This example authorizes users who belong to the Administrator , PowerUser or BackupAdministrator roles.
Добавление служб ролей в удостоверение Add Role services to Identity
Добавление аддролес для добавления служб ролей: Append AddRoles to add Role services:
ASP.NET — Безопасность в ASP.NET — Авторизация на основе ролей (Roles API)
Платформа ASP.NET поставляется с готовой к использованию инфраструктурой для управления и применения ролей (подобной Membership API). Эта инфраструктура, будучи полностью расширяемой через механизм поставщиков, такой как у Membership API, включает встроенную функциональность для управления ролями, назначения ролей пользователям и обращения ко всей информации о ролях в коде. Если говорить более подробно, то инфраструктура ролей включает перечисленные ниже аспекты:
Основанный на поставщиках механизм включения разных типов хранилищ данных, связанных с ролями.
Готовую к использованию реализацию поставщика для SQL Server и необходимые таблицы базы данных, основанные на данных членства. Эти таблицы ассоциируют записи о пользователях с ролями посредством отношения "многие ко многим" и создаются автоматически при вызове инструмента aspnet_regsql.exe (который также рассматривался ранее).
Предварительно построенный класс RolePrincipal, автоматически инициализируемый дня аутентифицированных пользователей через RoleManagerModule (также входящий в инфраструктуру ролей).
Полный программный доступ к ролям через класс Roles.
Чтобы использовать эту инфраструктуру, первым делом ее понадобится сделать доступной. Для этого необходимо либо отметить флажок Enable Roles for This Web Site (Разрешить роли для этого веб-сайта) при работе с мастером безопасности, либо щелкнуть на ссылке Enable Roles (Разрешить роли) на вкладке Security (Безопасность) в WAT:
В обоих случаях инструмент добавляет небольшой элемент конфигурации в файл web.config приложения. Это можно сделать и вручную, равно как и включить Roles API:
После появления этой конфигурации ASP.NET автоматически создает файловую базу данных ASPNETDB.MDF в каталоге приложения App_Data. Если хотите использовать собственное хранилище, выполните следующие шаги:
Создайте хранилище данных либо с помощью aspnet_regsql.exe, либо выполнив командные сценарии T-SQL, находящиеся в каталоге .NET Framework. И то, и другое объяснялось в статье «Настройка Membership API».
Сконфигурируйте поставщика ролей для использования ранее созданного хранилища.
Сконфигурировать поставщика ролей можно с помощью дескриптора . Можно либо использовать другую базу данных, либо полностью другое хранилище. Вдобавок посредством дескриптора можно настроить некоторые свойства, которые не могут быть сконфигурированы в среде WAT:
После добавления этого элемента конфигурации в файл web.config можно выбрать поставщика через WAT. Для этого нужно просто перейти в панель Provider (Поставщик) и щелкнуть на ссылке Select a Different Provider for Each Feature (Выбрать отдельного поставщика для каждой функции). Выбор поставщика в WAT показан на рисунке ниже:
В таблице ниже перечислены свойства, которые можно конфигурировать с помощью дескриптора :
| Свойство | Описание |
|---|---|
| enabled |
Указывает, включен интерфейс Roles API (true) или нет (false)
Необязательный атрибут, указывающий текущего активного поставщика для хранения информации о ролях. Если вы используете другого поставщика, то должны сконфигурировать его и установить значение атрибута defaultProvider равным имени необходимого поставщика
Вместо чтения ролей каждый раз из хранилища их можно сохранить в cookie-наборе. Этот атрибут указывает, используется ли cookie-набор
Если роли кэшируются в cookie-наборе, в этом атрибуте можно указать имя cookie-набора
Указывает корневой путь cookie-набора, где кэшируются роли для приложения. Это позволяет указать часть приложения, для которого cookie-набор действителен. Значение по умолчанию — /
Cookie-набор с ролями может быть зашифрован и подписан. В этом атрибуте указывается уровень защиты. Допустимые значения: All (шифровать и подписывать), Encryption, Validation и None
Указывает, должен ли cookie-набор возвращаться ASP.NET только в случае включенного SSL (true) или в любом другом случае (false). Если атрибут установлен в true, a SSL не активизирован, исполняющая среда просто не возвращает cookie-набор, а потому проверка ролей всегда осуществляется через лежащий в основе поставщик ролей
Получает или устанавливает таймаут для cookie-набора ролей в минутах. По умолчанию составляет 30 минут
Указывает, должен таймаут cookie-набора расширяться при каждом запросе пользователя к приложению ASP.NET (true) или нет (false). Значение по умолчанию — true
Если установлено в true, cookie-набор постоянно сохраняется на клиентской машине. В противном случае cookie-набор существует только в течение сеанса и удаляется, когда пользователь закрывает браузер
Указывает допустимый домен для cookie-набора ролей
Указывает максимальное количество имен ролей в cookie-наборе
В предыдущем примере конфигурировался поставщик SqlRoleProvider. Этот поставщик включает несколько дополнительных настроек, которые можно устанавливать в файле web.config. Все они перечислены в таблице ниже:
Имя поставщика. Это имя может быть использовано в атрибуте defaultProvider, описанном в предыдущей таблице, для указания поставщика для приложения
Имя приложения, для которого выполняется управление ролями
Краткое дружественное описание поставщика
Имя строки соединения, указанной в разделе файла web.config, которая будет использоваться для подключения к хранилищу ролей
В дополнение к SqlRoleProvider платформа ASP.NET содержит поставщик, который может быть использован на Windows Server 2003 с помощью диспетчера авторизации (Authorization Manager). Как будет показано позже, можно также создать и применять собственные специальные поставщики. В таблице ниже перечислены основные классы, входящие в Roles API:
Этот модуль гарантирует, что роли будут назначены текущему зарегистрированному пользователю при каждом запросе. Он прикрепляется к событию Application _AuthenticateRequest и создает экземпляр RolePrincipal, который содержит роли, назначенные пользователю, если Roles API разрешен в web.config
Базовый класс для каждого поставщика ролей, определяющий интерфейс, который следует реализовать в каждом RoleProvider. Каждый пользовательский поставщик ролей должен быть унаследован от этого класса
Коллекция поставщиков ролей. Эта коллекция позволяет выполнять итерацию по всем сконфигурированным поставщикам ролей в системе и для приложения, что полезно при написании административного приложения или отдельных страниц
Реализация поставщика ролей для баз данных SQL Server
Получает информацию о ролях для аутентифицированного пользователя Windows на основе групповых ассоциаций Windows
Реализация поставщика ролей для сохранения ролей в хранилище на основе диспетчера авторизации (Authorization Manager). Диспетчер Authorization Manager входит в состав Windows Server 2003 и позволяет декларативно определять роли приложений и привилегии этих ролей. Разрабатываемое приложение может использовать Authorization Manager для программной авторизации пользователей
Класс Roles служит первичным интерфейсом к хранилищу ролей. Этот класс включает методы для программного управления ролями
Реализация IPrincipal, которая подключается к сконфигурированным ролям с аутентифицированным пользователем. Создается автоматически модулем RoleManagerModule, если интерфейс Roles API разрешен
После конфигурирования Roles API можно создавать пользователей и роли, а затем назначать пользователей на эти роли с помощью либо WAT, либо класса Roles в коде. На вкладке Security (Безопасность) в WAT щелкните на ссылке Create or Manage Rotes (Создание ролей и управление ими). После этого можно будет создавать роли, а также добавлять к ним пользователей:
Когда включен Roles API, модуль RoleManagerModule автоматически создает экземпляр RolePrincipal, содержащий как идентичность аутентифицированного пользователя, так и его роли. RolePrincipal — это просто специальная реализация IPrincipal, базового интерфейса для всех классов принципалов. Поэтому он поддерживает функциональность по умолчанию, такую как доступ к аутентифицированной идентичности и метод для верификации условий членства в ролях через метод IsInRole().
Более того, он содержит несколько дополнительных свойств для доступа к более подробной информации о принципале. Эти свойства применяются в показанном ниже коде для извлечения информации из экземпляра, наряду с проверками авторизации с помощью метода IsInRole():
Использование элемента управления LoginView с ролями
Ранее вы ознакомились с подробностями об элементах управления безопасностью, поставляемых в составе ASP.NET. Одним из них был элемент LoginView. В статье, приведенной по ссылке, он применялся для отображения различных элементов управления для анонимных и зарегистрированных пользователей. Для реализации своей функциональности этот элемент управления использует шаблоны — и .
Этот элемент управления поддерживает один дополнительный шаблон, позволяющий строить различные представления на основе ролей, к которым принадлежит пользователь. Для этой цели потребуется добавить шаблон RoleGroup с элементами управления . Внутри каждого элемента в свойстве Roles указывается разделенный запятыми список ролей, для которых будет отображаться соответствующий шаблон :
Элемент управления LoginView в приведенном коде отображает различное содержимое для зарегистрированных пользователей и для пользователей, назначенных на специфические роли. Например, для пользователей в роли Admin он отображает текст "Только для админов", в то время как для пользователей из роли Guest выводится текст "Увидят только гости". LoggedInTemplate будет отображаться только для аутентифицированных пользователей без соответствующего элемента . Как только подходящая группа ролей для пользователя найдена, содержимое LoggedInTemplate не отображается.
Программный доступ к ролям
Как и в случае с интерфейсом Membership API интерфейс Roles API позволяет выполнять все задачи непосредственно в коде. Можно программно добавлять новые роли, читать информацию о ролях и удалять их из приложения. Более того, можно ассоциировать пользователей с ролями, а также извлекать пользователей, ассоциированных с определенной ролью. Все это делается с помощью методов класса Roles.
Большинство свойств класса Roles просто отображаются на настройки дескриптора , описанные выше. Поэтому в таблице ниже перечислены только дополнительные свойства и методы класса Roles, которые можно использовать для программного доступа и управления Roles API:
Возвращает поставщика, в данный момент используемого приложением
Возвращает коллекцию всех доступных для приложения поставщиков в системе. То есть возвращаются поставщики, сконфигурированные в файлах machine.config и web.config приложения
Принимает имя пользователя и имя роли как строковые параметры и добавляет указанного пользователя к указанной роли
Принимает имя пользователя как строковый параметр и имена ролей как массив строк, после чего добавляет указанного пользователя ко всем указанным ролям
Принимает массив строк с именами пользователей и строковый параметр с именем роли и добавляет указанных пользователей к указанной роли
Принимает строковый массив с именами пользователей и второй — с именами ролей, после чего добавляет всех указанных пользователей во все указанные роли
Создает новую роль
Удаляет существующую роль
Принимает строку, представляющую имя роли, и вторую строку, указывающую шаблон соответствия имен пользователей. Возвращает список пользователей, ассоциированных с ролью и соответствующих шаблону — второму параметру метода (usernameToMach)
Возвращает строковый массив, содержащий имена ролей, доступных в хранилище ролей сконфигурированного поставщика
Возвращает строковый массив, содержащий все роли, с которыми ассоциирован указанный пользователь. Есть также версия без параметров, которая извлекает роли текущего зарегистрированного пользователя
Возвращает список пользователей, которые ассоциированы с ролью, переданной в параметре
Возвращает true, если указанный пользователь является членом указанной роли
Удаляет отдельного пользователя из роли
Удаляет пользователя из всех указанных ролей
Удаляет всех указанных пользователей из одной указанной роли
Удаляет всех указанных пользователей из всех указанных ролей
Возвращает true, если роль существует, и false в противном случае
Удачным применением программного доступа к ролям является автоматическое ассоциирование пользователей с ролями при их самостоятельной первичной регистрации. Конечно, это удобно только для определенных ролей. Предположим, что приложение поддерживает роль под названием User, и каждый индивидуальный пользователь должен быть членом этой роли. Если вы регистрируете пользователя сами, то можете установить это отношение вручную. Но если приложение поддерживает автоматическую регистрацию для пользователей из Интернета, это делать нельзя. Поэтому нужно как-то обеспечивать автоматическую ассоциацию каждого пользователя с ролью User.
В качестве первой попытки можно решить перехватывать событие CreatedUser элемента управления CreateUserWizard, но этого недостаточно. Вспомните о существовании инструмента ASP.NET WAT, в котором можно создавать пользователей. В этом случае перехват события CreatedUser элемента управления, помещенного в ваше приложение, не поможет. Понадобится найти другое решение.
Определенно, для этой цели потребуется событие уровня приложения, хотя оно и не будет инициировано приложением конфигурации, поскольку это — другое приложение. Остается только перехват события Application. AuthenticateRequest — внутри этого события можно проверить, является ли пользователь членом роли User. Если нет, пользователь может быть добавлен автоматически. Это смещает задачу автоматического добавления пользователя к роли в точку аутентификации, которая по определению касается каждого пользователя. Чтобы сделать это, необходимо добавить в проект глобальный класс приложения (global.asax) и поместить в него приведенный ниже код:
Поступать подобным образом следует только с низкопривилегированными ролями, такими как User. Будет очень плохой идеей выполнять аналогичное действие с ролями другого типа.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago .
While there seems to be a lot of documentation about verifying roles, claims, etc with ASP.NET Core, there is little information about initially setting these things up in my app.
1 Answer 1
The best way to configure roles, claims, etc, is in your app startup. The new ASP.NET Core Dependency Injection makes setting this up a breeze if you know what you’re doing. Most of your work will happen in the Startup.cs file at the root of your project.
Don’t share your new user secrets with the world by hard-coding them into repositories that may be shared. Luckily, Microsoft has provided a great tool for this. This article explains it in detail: Safe Storage of App Secrets
To make sure this service is available later on, check the Startup constructor method in Startup.cs :
I’m using Entity Framework Core for my persistence store. This code was generated automatically when I created my application with the Web App template. But I’ll include it here for reference and troubleshooting (still in Startup.cs ):
This is where the real work starts. You’ll want to configure a role with full administrative privileges and assign a first user to that role. I have chosen to put that code in a private method in Startup.cs that I call from within the Configure method. First, the calling code:
I have found it useful to setup a static class that stores my role names. This allows me to check the names at compiletime, and gives me Intellisense help throughout my code when I need to invoke the role name elsewhere. It looks like this:
Having done that, now we get to set up our roles. Remember, I used ApplicationUser as my user type and ApplicationRole as my role type. You may name yours differently. Add these methods to the bottom of the Startup.cs file:
Now we setup the method that’s used to create the admin. We check to make sure that the user doesn’t exist yet. The user name is stored using the dotnet user secrets mentioned above. We also check to make sure that our primary admin role is created so that we can immediately assign this user to that role.
I hope this helped you. I had a heck of a time finding all this information scattered throughout the web. If you have any suggestions for improvement, please let me know!
