Архитектура безопасности в OData WebAPI

Question

Я пытаюсь создать архитектуру безопасности в службе OData WebAPI. Идея состоит в том, чтобы сделать развязанную архитектуру, уровень безопасности должен быть слабо связан с контроллерами WebAPI, то есть при обновлении контроллеров WebAPI мне не нужно обновлять уровень безопасности, мне просто нужно каким-то образом предоставить правила для уровня безопасности. Я хотел бы, если бы я мог сделать проверки безопасности на одном уровне, уровне безопасности и не включать бизнес-уровень для более сложных проверок. Я читал о предлагаемых решениях, и большинство из них в основном схожи, я должен использовать токены от поставщика токенов для аутентификации и роли от поставщика роли для авторизации. Авторизация выполняется путем пометки методов контроллера WebAPI с атрибутом Authorize. Например, у меня есть CompaniesController:

public class CompaniesController : ODataController 
{ 
    //code omitted 

    [Authorize("Admin,CompanyAdmin")] 
    public IQueryable<User> GetUsers() 
    { 
     //code for querying users from database... 
    } 
} 

Этот код позволит только клиентов с ролью администратора и/или CompanyAdmin для вызова метода компаний (ID)/GetUsers, где идентификатор уникальный ключ компании. Открытый ресурс - это набор пользователей, принадлежащих компании, с этим идентификатором. Я согласен, что этот подход - хорошая архитектура, но это не решает следующей проблемы: Я хочу иметь правило безопасности, которое позволит CompanyAdmin получать пользователей только от Компании, которые управляются этим CompanyAdmin. Это затрудняет решение о том, как достичь этого, и должно ли это быть «работой» уровня безопасности или бизнес-уровня.

1. Если уровень безопасности работы, идея заключается в следующем:

Добавить идентификацию CompanyAdmin в качестве претензии в маркер и проверить, что значение с идентификатором в URL запроса (ех/Компании (2)/GetUsers.), если он соответствует возвращаемым пользователям, в противном случае возвращает код состояния 401 Несанкционированный. Проверка выполняется в классе атрибута, полученном из атрибута Authorize - ex. [AdvancedAuthorize («Admin, CompanyAdmin {идентификация)»)] идентификация в скобках означает, что для уровня безопасности CompanyAdmin необходимо сравнить идентификационное значение от токена до значения id от URL-адреса

2. Если это бизнес-уровень работы, идея такова:

Получить идентификатор компанииAdmin от токена, то же, что 1. подходить или получать идентификацию из базы данных из таблицы авторизации, где у нас есть записи с разрешениями для каждого пользователя и проверить, совпадает ли идентификатор от URL-адреса , Метод бизнес-уровня вызывается из контроллера WebAPI, и я буду указывать id из URL-адреса в качестве параметра в методе бизнес-уровня.

Какой подход лучше? Или, может быть, какой-то другой подход лучше, чем оба?

Answer 1

Открытый ресурс в этом случае будет представлять собой коллекцию пользователей.

GET /companies/{company-id}/users 

Лично я бы с вашим вторым вариантом, потому что кажется проще реализовать.
В противном случае в пользовательском авторизационном фильтре потребуется какая-то бизнес-логика, чтобы определить, что компания, для которой запрашивается «подсектор» пользователей, управляется аутентифицированным пользователем.