Мне нужен механизм для пользовательской авторизации в классах бизнес-логики. Это должна быть система, основанная на разрешениях, но я не могу решить, как применять правила авторизации к методам.
Моей первой мыслью было применение пользовательских атрибутов к методу
[NeedPermission("Users", PermissionLevel.Read)]
public IList<User> GetAllUsers()
{
// some code goes here
}
Мой класс бизнес-логики имеет интерфейс, поэтому я могу использовать, например, поведение Unity Interception и проверять во время выполнения, есть ли у текущего пользователя необходимые разрешения. И бросить исключение, если он не имеет.
Но теперь меня беспокоит надежность этого метода.
Обычно ссылка на класс бизнес-логики, введенная контейнером единицы. Так что проблем нет, потому что он настроен на применение механизма перехвата интерфейса.
Но что, если какой-нибудь разработчик создаст экземпляр моего класса бизнес-логики напрямую? Тогда перехват не будет применен, и он сможет вызывать любой метод, даже если у текущего пользователя нет прав на выполнение каких-либо действий или даже он не аутентифицирован.
Также кто-то может изменить конфигурацию контейнера для единства, полностью отключить расширение перехвата. Опять моя система авторизации не будет работать.
Я видел, что ASP .NET MVC использует похожий механизм авторизации. Правило авторизации применяется только тогда, когда запрос поступил стандартным способом (IController.Execute). Я думаю, что это не проблема в этом случае, потому что конечный пользователь контроллера (веб-пользователь) не имеет никакого доступа к классу контроллера напрямую.
В моем случае конечный пользователь бизнес-логики - это программист, который разрабатывает интерфейс и может преднамеренно или непреднамеренно вмешиваться - создавать экземпляр класса бизнес-логики и вызывать любые методы.
Что вы можете мне предложить? Как вы справляетесь с такого рода проблемами?
Спасибо.