атрибут Authorize с ролями учитывает претензии

Question

Я пытался искать везде в сети, но, похоже, не могу понять эту важную часть.

В принципе, если мы каждый раз выполняем вызов БД при проверке принадлежности пользователя к роли - это отрицательно скажется на производительности.

Я видел примеры кода, в которых перечислены все роли пользователей, например,

var roles = ((ClaimsIdentity)User.Identity).Claims
            .Where(c => c.Type == ClaimTypes.Role)
            .Select(c => c.Value);

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

Из этого примера я делаю вывод, что в игру вступает Claims (кажется, это наиболее эффективное решение).

Я пытался выяснить , если атрибут Authorize с ролями проверяет утверждения пользователя , но официальная документация Microsoft не охватывает этот бит.

AuthorizeAttribute класс

Указывает, что доступ к контроллеру или методу действия ограничен пользователями, отвечающими требованиям авторизации.

Свойства:

Roles - Получает или задает роли пользователей, которым разрешен доступ к контроллеру или методу действия.

И это степень того, что мы имеем.

Answer 1

Оба атрибута Authorize, например, User.IsInRole взгляните на утверждения ролей User.Identity.

По умолчанию Орган (в который входит пользователь) добавляет роли из таблицы AspNetUserRoles в качестве утверждений типа 'http://schemas.microsoft.com/ws/2008/06/identity/claims/role'. См. WIF претензий членов .

Клиентское приложение автоматически получит информацию из токена / cookie и преобразует ее в User.Identity. Когда тип заявки совпадает, заявки типа роли отображаются как роли.

Это означает, что приложению не требуется доступ к хранилищу пользователей. В большинстве случаев это также невозможно. Так что на самом деле речь идет не о производительности, а о доступности. Обычно приложения не имеют доступа к контексту Identity. Так что UserManager не вариант.

Однако при использовании претензий существует недостаток. Информация датирована. Когда пользователь регистрирует моментальный снимок утверждений в это время, они добавляются в Идентичность. Если в то же время претензии (или роли) обновляются в базе данных, то эти изменения не отмечаются. Только после повторного входа пользователя изменения вступают в силу.

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

Вот почему я не рекомендовал бы использовать роли. Поскольку роли обычно используются для авторизации, но вы не можете в то же время отозвать доступ. Поэтому, пока вы не решите это, вы можете рассмотреть альтернативу.

Использование UserManager не является альтернативой, поскольку контекст может быть доступен не для всех приложений.

Именно поэтому авторизация на основе ресурсов может быть решением для вас. Пожалуйста, прочитайте мой ответ здесь для дополнительных мыслей.

Answer 2

Откройте ваш файл запуска и измените его:

services.AddDefaultIdentity<IdentityUser>()
.AddEntityFrameworkStores<ApplicationDbContext>();

к этому:

services.AddIdentity<IdentityUser, IdentityRole>()
                .AddEntityFrameworkStores<ApplicationDbContext>()
                .AddDefaultUI()
                .AddDefaultTokenProviders();

Тогда Роли должны начать работать.