2016-05-16 4 views
9

Политика авторизации Net Core, однако она выглядит очень статичной для меня. Потому что в Enterprise Application часто требуется наличие новых ролей, для которых потребуются новые политики (насколько я понимаю), или если вы хотите реализовать новый тип политики, специфичный для определенного клиента. Например, если мы создаем CMS, который будет управляться этими политиками, мы захотим, чтобы каждый клиент мог определить hes. Так может ли этот новый механизм политической базы быть более динамичным или, это идея совершенно другая?Может ли политическая авторизация быть более динамичной?

спасибо :))

+0

Перед тем как задать вопрос, я думал, как вы. (Http://stackoverflow.com/questions/36445780/how-to-implement-permission-based-access-control-with-asp-net-core). Но ответ Цзэн изменил мой разум. Ответ показывает, что «политическая авторизация» может использоваться динамически. Взгляните на ответ, это может быть полезно для вашего дела. –

+0

Вам больше не следует использовать «роли» (как раньше использовалось в ASP.NET 4.5/MVC 5), вместо этого используйте утверждения. Роли не очень гибкие и требуют, чтобы вы меняли свой код каждый раз, когда добавляете новую роль.Требование представляет собой конкретное разрешение, основанное на признаке вашего приложения, то есть «ReadArticle» или «WriteArticle», «DeleteArticle», «CreateUser» и т. Д. Таким образом, вам нужно добавить политику только при добавлении новой функции (например, способность управлять пользователями или публиковать статьи). «Роль» будет просто просто набором требований, которые пользователь имеет при входе в систему. Затем проверьте его в политике – Tseng

+1

Просто имейте в виду, вы не можете создать динамическую политику, если раньше не было. не может позволить пользователю указать политику «старше 18 лет», если в бэкэнд, который ее обрабатывает, нет кода (например, политика «AgeOver18» и обработчик, который проверяет возраст пользователя). Таким образом, политика не может быть создан не разработчиком или кем-то, у кого нет доступа к исходному коду (поскольку вам необходимо добавить проверки к этой конкретной политике в коде). Вместо создания новой политики вы создаете роль существующие политики/разрешения. – Tseng

ответ

13

Я всегда рекомендую, чтобы люди смотрели @ в least privilege repo, как это имеет некоторые большие примеры всех различных подходов, можно взять с новым ASP.NET ядра аутентификации и авторизации парадигм ,

Может ли этот новый механизм базовой политики быть более динамичным?

Да, на самом деле это более динамично, чем предыдущие концепции, основанные на ролях. Он позволяет вам определять политики, которые могут управляться данными. Here - еще один отличный ресурс для деталей, относящихся к этому. Вы можете указать, что точка входа API, например, защищена политикой (например), и эта политика может иметь обработчик, и этот обработчик может делать все, что ему нужно, т. Е. изучите текущий User в контексте, сравните требования к значениям в базе данных, сравните роли, что-нибудь действительно. Рассмотрим following:

Определить точку входа с Policy

[Authorize(Policy = "DataDrivenExample")] 
public IActionResult GetFooBar() 
{ 
    // Omitted for brevity... 
} 

Добавить авторизацию с параметрами, которые добавляют политику.

public void ConfigureServices(IServiceCollection services) 
{ 
    services.AddMvc();  
    services.AddAuthorization(options => 
    { 
     options.AddPolicy("DataDrivenExample", 
          policy => 
          policy.Requirements.Add(new DataDrivenRequirement())); 
    });  
    services.AddSingleton<IAuthorizationHandler, DataDrivenHandler>(); 
} 

Затем определите обработчик.

public class MinimumAgeHandler : AuthorizationHandler<DataDrivenRequirement> 
{ 
    protected override void Handle(AuthorizationContext context, 
            DataDrivenRequirement requirement) 
    { 
     // Do anything here, interact with DB, User, claims, Roles, etc. 
     // As long as you set either: 
     // context.Succeed(requirement); 
     // context.Fail(); 
    } 
} 

Есть идея совсем по-другому?

Он должен чувствовать себя очень похоже на предыдущие концепции, которые вы привыкли с auth8 и AuthZ.

+0

Спасибо, это все, что мне нужно знать :))) –

6

Принятый ответ по-прежнему весьма ограничен. Он не учитывает динамические значения на уровне контроллера и Action. Единственное место, в которое может быть добавлено пользовательское значение, - это требование при добавлении политики. Иногда вам требуется более мелкий контроль над процессом авторизации. Очень распространенным сценарием является безопасность на основе разрешений. Каждый контроллер и действие должны иметь возможность указывать разрешения, необходимые для доступа к ним. См. Мой ответ here для более мощного решения, которое позволяет использовать пользовательские атрибуты для украшения ваших контроллеров и действий с любой информацией, необходимой вам при авторизации.

+0

https://github.com/aspnet/Security/issues/1359 следует адресовать это – thekip

Смежные вопросы