Asp.net Core WebAPI Авторизация на основе ресурсов вне уровня контроллера

Использование атрибута [Authorize] называется декларативной авторизацией. Но он выполняется до выполнения контроллера или действия. Если вам нужна авторизация на основе ресурсов, а документ имеет свойство автора, вы должны загрузить документ из хранилища перед оценкой авторизации. Это называется императивной авторизацией.

Существует сообщение в Microsoft Docs, как работать с императивной авторизацией в ASP.NET Core. Я думаю, что он достаточно всеобъемлющий и отвечает на ваш вопрос о стандартном подходе.

Также здесь вы можете найти образец кода.

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

Я использую интерфейс, чтобы указать, какие записи данных относятся к учетной записи.

public interface IAccountOwnedEntity
{
    Guid AccountKey { get; set; }
}

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

public interface IAccountResolver
{
    Guid ResolveAccount();
}

Реализация IAccountResolver, которую я использую сегодня, основана на утверждениях аутентифицированных пользователей.

public class ClaimsPrincipalAccountResolver : IAccountResolver
{
    private readonly HttpContext _httpContext;

    public ClaimsPrincipalAccountResolver(IHttpContextAccessor httpContextAccessor)
    {
        _httpContext = httpContextAccessor.HttpContext;
    }

    public Guid ResolveAccount()
    {
        var AccountKeyClaim = _httpContext
            ?.User
            ?.Claims
            ?.FirstOrDefault(c => String.Equals(c.Type, ClaimNames.AccountKey, StringComparison.InvariantCulture));

        var validAccoutnKey = Guid.TryParse(AccountKeyClaim?.Value, out var accountKey));

        return (validAccoutnKey) ? accountKey : throw new AccountResolutionException();
    }
}

Затем в репозитории я ограничиваю все возвращаемые записи тем, что они принадлежат этой учетной записи.

public class SqlRepository<TRecord, TKey>
    where TRecord : class, IAccountOwnedEntity
{
    private readonly DbContext _dbContext;
    private readonly IAccountResolver _accountResolver;

    public SqlRepository(DbContext dbContext, IAccountResolver accountResolver)
    {
        _dbContext = dbContext;
        _accountResolver = accountResolver;
    }

    public async Task<IEnumerable<TRecord>> GetAsync()
    {
        var accountKey = _accountResolver.ResolveAccount();

        return await _dbContext
                .Set<TRecord>()
                .Where(record => record.AccountKey == accountKey)
                .ToListAsync();
    }


    // Other CRUD operations
}

При таком подходе мне не нужно помнить о применении ограничений моей учетной записи для каждого запроса. Просто это происходит автоматически.

Чтобы убедиться, что пользователь A не может просматривать заказ с идентификатором = 2 (принадлежит пользователю B). Я бы сделал одну из этих двух вещей:

Во-первых: у вас есть GetOrderByIdAndUser(long orderId, string username), и, конечно же, вы берете имя пользователя из jwt. Если пользователь не владеет заказом, он его не увидит, и никакого дополнительного db-вызова.

Второе: сначала извлеките заказ GetOrderById(long orderId) из базы данных, а затем убедитесь, что свойство имени пользователя заказа совпадает с именем пользователя, вошедшего в систему в jwt. Если пользователю не принадлежит исключение Throw для заказа, верните 404 или что-то еще, и никаких дополнительных вызовов db.

void ValidateUserOwnsOrder(Order order, string username)
{
            if (order.username != username)
            {
                throw new Exception("Wrong user.");
            }
}

Вы можете создать несколько политик в методе ConfigureServices вашего запуска, содержащих роли или, в соответствии с вашим примером здесь, имена, например:

AddPolicy("UserA", builder => builder.RequireClaim("Name", "UserA"))

или замените "UserA" на "Accounting" и "Name" на "Role".
Затем ограничьте методы контроллера по роли:

[Authorize(Policy = "UserA")

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

Ваши утверждения неверны, и вы также неправильно их разрабатываете.

Излишняя оптимизация — корень всех зол

Эту ссылку можно резюмировать как «проверьте производительность, прежде чем утверждать, что она не будет работать».

Использование удостоверения (токена jwt или того, что вы настроили) для проверки того, обращается ли фактический пользователь к нужному ресурсу (или, может быть, лучше обслуживать только те ресурсы, которыми он владеет) не слишком сложно. Если он становится тяжелым, вы делаете что-то не так. Может случиться так, что у вас есть тонны одновременных доступов, и вам просто нужно кэшировать некоторые данные, такие как порядок словаря-> идентификатор владельца, который со временем очищается ... но это не так.

о дизайне: создайте сервис многократного использования, который можно вводить, и иметь метод доступа к каждому ресурсу, который вам нужен, который принимает пользователя (IdentityUser или тема jwt, просто идентификатор пользователя или что у вас есть)

что-то вроде

ICustomerStore 
{
    Task<Order[]> GetUserOrders(String userid);
    Task<Bool> CanUserSeeOrder(String userid, String orderid);
}

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

Первый вопрос, на который вам нужно ответить: «Когда я могу принять это решение об авторизации?». Когда у вас действительно есть информация, необходимая для проверки?

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

Если вы не можете понять, может ли пользователь возиться с ресурсом, пока вы его не изучите, то вы в значительной степени застряли с императивными проверками. Существует стандартная структура. для этого, но это не так полезно, как структура политики. Вероятно, в какой-то момент будет полезно написать IUserContext, который можно будет внедрить в тот момент, когда вы запрашиваете свой домен (то есть в репозитории/где бы вы ни использовали linq), который инкапсулирует некоторые из этих фильтров (IEnumerable<Order> Restrict(this IEnumerable<Order> orders, IUserContext ctx)).

Для сложного домена не будет простой серебряной пули. Если вы используете ORM, это может помочь вам, но не забывайте, что навигационные отношения в вашем домене позволят коду нарушать контекст, особенно если вы не были строги в попытке сохранить агрегаты изолированными (myOrder.Items[ n].Product.Orderees[notme]...).

В прошлый раз, когда я делал это, мне удалось использовать подход на основе политики на маршруте в 90% случаев, но все еще приходилось выполнять некоторые императивные проверки вручную для нечетного списка или сложного запроса. Опасность использования императивных проверок, как я уверен, вы знаете, заключается в том, что вы забываете о них. Потенциальное решение для этого состоит в том, чтобы применить ваш [Authorize(Policy = "MatchingUserPolicy")] на уровне контроллера, добавить дополнительную политику «ISolemlySwearIHaveDoneImperativeChecks» для действия, а затем в вашем MatchUserRequirementsHandler проверить контекст и обойти наивные проверки соответствия пользователя/заказа, если императивные проверки были «объявлены». '.