MVC настраиваемый фильтр авторизации - PullRequest
Новая
       27

MVC настраиваемый фильтр авторизации

0 голосов
/ 23 апреля 2019

Я хочу сделать атрибут [MyAuthorize(Role="R1")], чтобы "R1" можно было настраивать вместо жесткого кодирования на Controller / Action.

Обычный подход к созданию [MyAuthorize(Role="R1")] выглядит как 

public class MyAuthorizeAttribute : AuthorizeAttribute
{
    private readonly string[] _allowedRoles;

    public MyAuthorizeAttribute(params string[] roles)
    {
        this._allowedRoles = roles;
    }
    protected override bool OnAuthorization(AuthorizationContext 
                                             authorizationContext)

    {
        bool authorize = false;

        // Compare current user's Roles with "R1" to figure out if the 
        // Action / Controller can be executed   

        return authorize;
    }
}

Но что, если роли, подобные "R1", могут быть изменены в любое время?то есть быть "R1" одним днем ​​и называться "AssistantManager" другим днем.

Приложение должно быть перекодировано, чтобы справиться с этим.

Я думал о создании пользовательского атрибута [OnAuthorize], который читает (Action / Controller, Role) как key value pairs изweb.config.

Например: - 

  <add key="Controller1" value="Role1" />
  <add key="Action2" value="Role2" />

и в атрибуте .. 

protected override bool OnAuthorization(AuthorizationContext 
                                         authorizationContext)

{
    bool authorize = false;

    // 1. Read all key values 
    // 2. determine Action / Controller the user is trying to go
    // 3. Compare user's roles with those for Action / Controller

    return authorize;
}

Я знаю об ограничениях <location .... /> в MVC согласно https://stackoverflow.com/a/11765196/807246 и я не предполагаю, что, хотя я читаю из web.config

Но что, если мы прочитаем (... и сохраним в сеансе ??) всю конфигурацию, связанную с авторизацией, при первой загрузке приложенияup?

Любые изменения, такие как "R1" -> "AssistantManager" ;;"R2" -> "Manager" должен просто потребовать перезапуска приложения, вместо того, чтобы вносить изменения в код в контроллере / действии.

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

1 Ответ

1 голос
/ 23 апреля 2019

Объявление 1. Вы читаете настройки с помощью API конфигурации, например, если это обычный MVC, вы должны ConfigurationManager.AppSettings заглянуть в раздел настроек приложения web.config

Объявление 2. Вы не определяете что-либо или, скорее, вы, кажется, неправильно поняли связанный пост. Что вы делаете, вы помещаете Authorize над контроллером (действие), которое вы хотите защитить, и OnAuthorization запускается, когда контроллер / действие выполняется. Если вы действительно хотите, вы можете заглянуть в контекст авторизации, переданный в качестве аргумента, контроллер и действие доступны в данных маршрута.

Объявление 3. Это самая простая часть: текущий зарегистрированный пользователь (или анонимный пользователь, если пользователь еще не аутентифицирован) передается в свойстве authorizationContext.HttpContext.User как IPrincipal, так что вы даже можете вызвать его IsInRole метод.

Но что, если мы прочитаем (..и сохраним в сеансе ??) всю конфигурацию, связанную с авторизацией, когда приложение впервые загрузится

Тебе действительно не нужно. Даже если вы читаете его из конфигурации при каждом запросе, конфигурация уже предварительно загружается при каждом перезапуске приложения, вы ничего не сильно замедляете, тогда как ConfigurationManager.AppSettings.

Любые изменения, такие как "R1" -> "AssistantManager" ;; «R2» -> «Диспетчер» должен просто потребовать перезапуска приложения, вместо того, чтобы вносить изменения кода в контроллер / действие.

Если вы сохраните его в файле конфигурации и, изменив его, запустите перезапуск пула приложений, вы не внесете никаких изменений в код.

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

Есть риски, кто-то, кто может получить доступ к вашему серверу приложений, может перенастроить ваше приложение. Обратите внимание, однако, что такой человек может также причинить любой другой вред, например, декомпилировать, изменять, перекомпилировать и перезагружать ваше приложение. Или даже заменить его чем-то совершенно другим.

Что касается альтернатив, совершенно невозможно придумать что-нибудь лучше , если критерии того, что лучше, расплывчаты. Если что-то возможно лучше , мы должны знать, что означает лучше .

Другими словами, это выглядит хорошо.

...