Can Policy Based Authorization be more dynamic?

Question

Net Core policy authorization, however it is looking very static to me. Because in the Enterprise Application, there is an often need for new roles which will need new policies (as far as i understand) or if you want to implement new type of policy specific for certain client. For example if we are building an CMS which will be driven by those policies, we will want, each client to be able to define hes own. So can this new policy base mechanism be more dynamic or, it's idea is entire different?

thanks :))

Answer 1

I always recommend that people take a look @ the least privilege repo as it has some great examples of all the various approaches one can take with the new ASP.NET Core Authentication and Authorization paradigms.

Can this new policy base mechanism be more dynamic?

Yes, in fact it is more dynamic than the previous role based concepts. It allows for you to define policies that can be data driven. Here is another great resource for details pertaining to this. You can specify that an API entry point for example is protected by a policy (for example), and that policy can have a handler and that handler can do anything it needs to, i.e.; examine the current User in context, compare claims to values in the database, compare roles, anything really. Consider the following:

Define an entry point with the Policy

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

Add the authorization with the options that add the policy.

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

Then define the handler.

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();     } } 

Is the idea entirely different?

It should feel very similar to the previous concepts that you're accustomed to with auth8 and authz.