.NET Core 2.1 MVC Identity Authorization - разные роли пользователей для разных частей - PullRequest
Новая
       96

.NET Core 2.1 MVC Identity Authorization - разные роли пользователей для разных частей

0 голосов
/ 26 июня 2018

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

  1. Пользователь A является администратором проекта A
  2. Пользователь A является наблюдателем для проекта B (только для чтения)
  3. Пользователь A не имеет роли Project C (не может получить доступ к проекту)
  4. Пользователь B является администратором проекта B
  5. Пользователь B является наблюдателем для проекта C (только для чтения)

Кажется, идентичность не поддерживает это поведение. Авторизация на основе утверждений поддерживает статические утверждения, но не динамические (доступ к проекту с идентификатором). Я могу создать свой собственный класс UserProjectRoles, который связывает пользователя, проекты и роли, и использовать его в обработчике авторизации (авторизация на основе политик), но мне было интересно, является ли это правильным решением. Как бы вы решили эту задачу?

Edit:

Я закончил тем, что сделал следующее: я создал новую таблицу UserProjectClaims, которая связывает пользователей и проекты и содержит тип роли в виде enum (я перенесу тип роли / заявки в свою собственную таблицу, это было только для ради тестирования). 

public class UserProjectClaim
{
    public int ProjectId { get; set; }
    public Project Project { get; set; }

    public int UserId { get; set; }
    public AppUser User { get; set; }

    public UserProjectClaimEnum ClaimType { get; set; }
}

Затем я использовал эту таблицу в AuthorizationHandler, как показано в руководстве по авторизации на основе политик: 

protected override async Task HandleRequirementAsync(AuthorizationHandlerContext context, ProjectAdminRequirement requirement)
{
    if (context.Resource is AuthorizationFilterContext authContext)
    {
        var projectId = Int32.Parse(authContext.HttpContext.Request.Query["projectId"]);
        var userid = (await _userManager.GetUserAsync(context.User)).Id;
        var claim = _dbContext.AppUsers.Include(i=>i.UserProjectClaims).Single(u=>u.Id==userid).UserProjectClaims.SingleOrDefault(p => p.ProjectId == projectId);      

        if (claim != null && claim.ClaimType == Data.Enums.UserProjectClaimEnum.ProjectAdmin)
        {
            context.Succeed(requirement);
        }
        else
        {
            context.Fail();
        }
    }           
}

И он работает как положено.

1 Ответ

0 голосов
/ 26 июня 2018

После создания нового веб-приложения (MVC) с индивидуальными учетными записями пользователей (VS2017) вы найдете такие таблицы, как AspNetRoles, AspNetRoleClaims, AspNetUserRoles, AspNetUserClaims как часть ядра Entity Framework IdentityContext.

В AccountController введен UserManager, но нет методов для обслуживания ролей и утверждений. Представления (страницы), контроллеры и модели не поставляются для управления отношениями из коробки.

Хорошая новость заключается в том, что UserManager обладает всевозможными функциями для добавления заявок и ролей пользователям. AddClaimAsync, AddToRoleAsync, GetClaimsAsync, GetRolesAsync, GetUsersForClaimAsync, GetUsersInRoleAsync, RemoveClaimAsync, RemoveFromRoleAsync и версии, которые обрабатывают заявки / роли как IEnumerable.

Краткосрочное решение: не должно быть сложной задачей добавить методы в AccountController или ManageController или даже создать RolesController для поддержки страниц, которые управляют этими отношениями.

Долгосрочное решение: узнайте, как добавлять шаблоны для создания этих элементов при создании нового проекта MVC Identity. Затем похвастайтесь, обнародовав его в GitHub :) Или напишите статью о том, что вы узнали для других людей в вашей ситуации.

Postscript: Создав небольшое промежуточное ПО, которое вы поместили в путь обработки запросов, вы можете загрузить роли / утверждения для текущего пользователя, на которые может ссылаться остальная часть обработки запросов. Таблица соединения между проектами и ролями, возможно, с ролями чтения и роли записи, позволяет сравнивать роли, требуемые с ролями / утверждениями пользователя.

Техника: Здесь - потрясающее объяснение пользовательских политик и авторизации. В вашем случае политика проверит, соответствует ли пользователь роли / заявке, соответствующей вашему проекту. Ваши роли выше - «Прочитать проект», «Написать проект». Если ни того, ни другого нет доступа.

...