Как защитить веб-API от поиска данных не от владельца ресурса

У меня есть asp.net web api.

Я хочу, чтобы собственный веб-API для самостоятельного использования позже был на лазурном веб-сайте.

Зарегистрированный пользователь может сделать это в браузере /api/bankaccounts/3

чтобы получить все детали около bank account number 3.

Но зарегистрированный пользователь не является владельцем bank account number 3.

Как мне создать мои контроллеры и сервисы, за которыми регистрируется

пользователь может извлекать/изменять собственные ресурсы в базе данных?

ОБНОВЛЕНИЕ

После того, как я создал a:

public class UserActionsAuthorizationFilter : AuthorizationFilterAttribute
{
   public override void OnAuthorization(HttpActionContext actionContext)
   {
       if (actionContext != null)
       { 
           bool canUserExecuteAction = IsResourceOwner(actionContext);
           // stop propagation  
       }
   }

private bool IsResourceOwner(HttpActionContext actionContext)
        {
            var principal = (ClaimsPrincipal)Thread.CurrentPrincipal; 
            var userIdAuthenticated = Convert.ToInt32(principal.Claims.Single(c => c.Type == ClaimTypes.Sid).Value);

            int targetId = Convert.ToInt32(actionContext.Request.GetRouteData().Values["Id"]);
            var requstScope = actionContext.ControllerContext.Request.GetDependencyScope();
            var service = (ISchoolyearService)requstScope.GetService(typeof(ISchoolyearService));
            bool canUserExecuteAction = service.HasUserPermission(userIdAuthenticated, targetId);
            return canUserExecuteAction;
        }
}

Вопрос в том, что IsResouceOwner жестко запрограммирован на определенную службу = > SchoolyearService, привязанную к таблице SQL Schoolyear

Мне нужно, чтобы метод IsResourceOwner работал в основном для всех таблиц sql, имеющих поле UserId/UserEmail.

Проблема - и я действительно думаю, что никто не делает этого таким образом - что я должен сопоставить каждую проверку владельца ресурса с правильной таблицей Sql в методе HasUserPermission.

Как должно выглядеть это сопоставление?

Проверьте имя контроллера "SchoolyearController", таким образом, таблица для проверки - это таблица "schoolyear"? Это смешно.

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

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

Я думаю, я не могу решить это внутри фильтра.

Я должен разрешить поиск/модификацию данных через контроллер и выполнить проверку ResourceOwner внутри, может быть, в репозитории непосредственно перед извлечением данных.

Что вы думаете об этом:

API

public async Task<IHttpActionResult> Delete(int id)
{
   var result = await service.Delete(id, User.Identity.UserId);
    if (result == 0)
        return NotFound();
    return Ok();
}

REPO

    public async Task<int> Delete(int id, int userId)
    {
        var schoolyerToDelete = await context.Schoolyears.SingleOrDefaultAsync(s => s.Id == id && s.UserId == userId); 

// If schoolyearToDelete is null nothing is removed, thus the affected rows are ZERO.
        context.Schoolyears.Remove(schoolyerToDelete);
       return await context.SaveChangesAsync();
    }
  • Для метода Get ничего не возвращается для неправильного UserId
  • Для метода Create: нет проблем, каждый должен иметь возможность создавать ресурс при входе в систему.
  • Для метода обновления: то же, что и метод Delete, учебный год извлекается с помощью id и UserId.

Как правило, каждый метод в моем репозитории должен учитывать UserId в действии CRUD.

Как вы думаете?

Ответ 1

См. следующую ссылку: она охватывает как аутентификацию (поэтому вы знаете, кто запрашивает), так и авторизацию (чтобы вы знали, разрешены ли они для просмотра данных):

http://www.asp.net/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api

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