Я хотел бы предоставить детализированные разрешения для моего нового приложения ASP.NET Core 3. В приложении будет много областей (пара при запуске, но каждая новая функция будет сопровождаться другой областью для контроля доступа), и я подозреваю, что рано или поздно мне потребуется точный контроль доступа (например, этот пользовательдолжен иметь доступ к тому, что Employee может иметь ПЛЮС области X, Y RW и область Z RO).
Самостоятельно реализовать такой механизм, но я бы хотел использовать встроенные механизмы ASP, чтобы не записывать все изцарапина. Исходя из того, что я читал о механизмах авторизации в ASP.NET Core, я бы пошел следующим образом:
- Предоставление утверждений для пользователей, которые будут контролировать доступ к определенной области с помощью флага (скажем,, List, Read, Write, Delete, Admin)
- Создать реализацию
IAuthorizationPolicyProvider, которая бы на лету создавала определенные политики на основе переданного параметра, скажем: [Authorize(Policy = "Area1,r")] или [Authorize(Policy = "Area5,a")] (с использованием обработчиков)создано на лету) - Зарегистрируйте мой пользовательский
IAuthorizationPolicyProvider в системе внедрения зависимостей
Если честно, мне кажется, что для меня это немного сложнее, чем я могу реализоватьмой собственный атрибут авторизации, который - для начала - упростил бы ввод ограничений (в том смысле, что ошибки в определении доступа будут обнаруживаться во время компиляции, а не во время работы приложения):
[RestrictAccess(Areas.Area1, AreaAccess.Read)]
public IActionResult MyAction() { }
Однако, похоже, этобыть решением, которое уклоняется от использования механизмов ASP.NET Core, потому что тот, который я представил ранее, кажется, как Microsoft хочет, чтобы мы использовалиполитики (см. Пользовательская политика авторизации )
TL; DR: Каков правильный способ реализации таких детальных разрешений в ASP.Net Core 3? И, кроме того, каковы реальные преимущества реализации разрешений, предлагаемых Microsoft?