基于资源的授权

有些场景下,授权需要依赖于要访问的资源,例如:每个资源通常会有一个创建者属性,我们只允许该资源的创建者才可以对其进行编辑,删除等操作,这就无法通过[Authorize]特性来指定授权了。因为授权过滤器会在我们的应用代码,以及MVC的模型绑定之前执行,无法确定所访问的资源。此时,我们需要使用基于资源的授权,下面就来演示一下具体是如何操作的。

定义资源Requirement

在基于资源的授权中,我们要判断的是用户是否具有针对该资源的某项操作,因此,我们先定义一个代表操作的Requirement:

public class MyRequirement : IAuthorizationRequirement{    public string Name { get; set; }
}

可以根据实际场景来定义需要的属性,在本示例中,只需要一个Name属性,用来表示针对资源的操作名称(如:增查改删等)。

然后,我们预定义一些常用的操作,方便业务中的调用:

public static class Operations{        public static MyRequirement Create = new MyRequirement { Name = "Create" };    

public static MyRequirement Read = new MyRequirement { Name = "Read" };    public static MyRequirement Update = new MyRequirement { Name = "Update" };  public static MyRequirement Delete = new MyRequirement { Name = "Delete" };
}

上面定义的 MyRequirement 虽然很简单,但是非常通用,因此,在 ASP.NET Core 中也内置了一个OperationAuthorizationRequirement

public class OperationAuthorizationRequirement : IAuthorizationRequirement{    public string Name { get; set; }
}

在实际应用中,我们可以直接使用OperationAuthorizationRequirement,而不需要再自定义 Requirement,而在这里只是为了方便理解,后续也继续使用 MyRequirement 来演示。

实现资源授权Handler

每一个 Requirement 都需要有一个对应的 Handler,来完成授权逻辑,可以直接让 Requirement 实现IAuthorizationHandler接口,也可以单独定义授权Handler,在这里使用后者。

在本示例中,我们是根据资源的创建者来判断用户是否具有操作权限,因此,我们定义一个资源创建者的接口,而不是直接依赖于具体的资源:

public interface IDocument{    string Creator { get; set; }
}

然后实现我们的授权Handler:

public class DocumentAuthorizationHandler : AuthorizationHandler<OperationAuthorizationRequirement, IDocument>
{    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, OperationAuthorizationRequirement requirement, IDocument resource)    {        // 如果是Admin角色就直接授权成功if (context.User.IsInRole("admin")){context.Succeed(requirement);}        else{            // 允许任何人创建或读取资源if (requirement == Operations.Create || requirement == Operations.Read){context.Succeed(requirement);}            else{                // 只有资源的创建者才可以修改和删除if (context.User.Identity.Name == resource.Creator){context.Succeed(requirement);}                 else{context.Fail();}}}        return Task.CompletedTask;}
}

在前面章节的《自定义策略》示例中,我们继承的是AuthorizationHandler<NameAuthorizationRequirement>,而这里继承了AuthorizationHandler<OperationAuthorizationRequirement, Document>,很明显,比之前的多了resource参数,以便用来实现基于资源的授权。

如上,我们并没有验证用户是否已登录,以及context.User是否为空等。这是因为在 ASP.NET Core 的默认授权中,已经对这些进行了判断,我们只需要在要授权的控制器上添加[Authorize]特性即可,无需重复性的工作。

最后,不要忘了,还需要将DocumentAuthorizationHandler注册到DI系统中:

services.AddSingleton<IAuthorizationHandler, DocumentAuthorizationHandler>();

调用AuthorizationService

现在就可以在我们的应用代码中调用IAuthorizationService来完成授权了,不过在此之前,我们再来回顾一下IAuthorizationService接口:

public interface IAuthorizationService{   

 Task<AuthorizationResult> AuthorizeAsync(ClaimsPrincipal user, object resource, IEnumerable<IAuthorizationRequirement> requirements);     Task<AuthorizationResult> AuthorizeAsync(ClaimsPrincipal user, object resource, string policyName);
}

在《上一章》中,我们提到,使用[Authorize]设置授权时,其AuthorizationHandlerContext中的resource字段被设置为空,现在,我们将要授权的资源传进去即可:

[Authorize]public class DocumentsController : Controller{  

  public async Task<ActionResult> Details(int? id)    {          var document = _docStore.Find(id.Value);            if (document == null){                   return NotFound();}              if ((await _authorizationService.AuthorizeAsync(User, document, Operations.Read)).Succeeded){                   return View(document);}               else{                   return new ForbidResult();}}    

public async Task<IActionResult> Edit(int? id)    {        var document = _docStore.Find(id.Value);           if (document == null){                  return NotFound();}             if ((await _authorizationService.AuthorizeAsync(User, document, Operations.Update)).Succeeded){                 return View(document);}              else{                   return new ForbidReuslt();}}
}

如上,在授权失败时,我们返回了ForbidResult,建议不要返回ChallengeResult,因为我们要明确的告诉用户是无权访问,而不是未登录。

基于资源的权限非常简单,但是每次都要在应用代码中显示调用IAuthorizationService,显然比较繁琐,我们也可以使用AOP模式,或者使用EF Core拦截器来实现,将授权验证与业务代码分离。

基于权限的授权

在一个通用的用户权限管理系统中,通常每一个Action都代表一种权限,用户拥有哪些权限也是可以动态分配的。本小节就来介绍一下在 ASP.NET Core 中,如何实现一个简单权限管理系统。

定义权限项

首先,我们要确定我们的系统分为哪些权限项,这通常是由业务所决定的,并且是预先确定的,我们可以硬编码在代码中,方便统一调用:

public static class Permissions{    public const string User = "User";    public const string UserCreate = "User.Create";     public const string UserRead = "User.Read";       public const string UserUpdate = "User.Update";         public const string UserDelete = "User.Delete";
}

如上,我们简单定义了“创建用户”,“查询用户”,“更新用户”,“删除用户”四个权限。通常会对权限项进行分组,构成一个树形结构,这样在展示和配置权限时,都会方便很多。在这里,使用.来表示层级进行分组,其中User权限项包含所有以User.开头的权限。

定义权限Requirement

与基于资源的授权类似,我们同样需要定义一个权限Requirement

public class PermissionAuthorizationRequirement : IAuthorizationRequirement{    public PermissionAuthorizationRequirement(string name)    {Name = name;}    public string Name { get; set; }
}

使用Name属性来表示权限的名称,与上面Permissions的常量对应。

实现权限授权Handler

然后实现与上面定义的 Requirement 对应的授权Handler:

public class PermissionAuthorizationHandler : AuthorizationHandler<PermissionAuthorizationRequirement>
{    private readonly UserStore _userStore;   

  public PermissionAuthorizationHandler(UserStore userStore)    {_userStore = userStore;}   

  protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, PermissionAuthorizationRequirement requirement)    {          if (context.User != null){                  if (context.User.IsInRole("admin")){context.Succeed(requirement);}                  else{                         var userIdClaim = context.User.FindFirst(_ => _.Type == ClaimTypes.NameIdentifier);                           if (userIdClaim != null){                                 if (_userStore.CheckPermission(int.Parse(userIdClaim.Value), requirement.Name)){context.Succeed(requirement);}}}}             return Task.CompletedTask;}
}

如上,把admin角色设置为内部固定角色,直接跳过授权检查。其他角色则从Claims中取出用户Id,然后调用CheckPermission完成授权。

权限检查的具体逻辑就属于业务层面的了,通常会从数据库中查找用的的权限列表进行验证,这里就不在多说,简单模拟了一下:

public class UserStore{    private static List<User> _users = new List<User>() {         new User {  Id=1, Name="admin", Password="111111", Role="admin", Email="admin@gmail.com", PhoneNumber="18800000000"},             new User {  Id=2, Name="alice", Password="111111", Role="user", Email="alice@gmail.com", PhoneNumber="18800000001", Permissions = new List<UserPermission> {                       new UserPermission { UserId = 1, PermissionName = Permissions.User },                        new UserPermission { UserId = 1, PermissionName = Permissions.Role }}},                new User {  Id=3, Name="bob", Password="111111", Role = "user", Email="bob@gmail.com", PhoneNumber="18800000002", Permissions = new List<UserPermission> {                      new UserPermission { UserId = 2, PermissionName = Permissions.UserRead },                        new UserPermission { UserId = 2, PermissionName = Permissions.RoleRead }}},};    

public bool CheckPermission(int userId, string permissionName)    {        var user = Find(userId);        if (user == null) return false;          return user.Permissions.Any(p => permissionName.StartsWith(p.PermissionName));}
}

最后,与上面示例一样,将Handler注册到DI系统中:

services.AddSingleton<IAuthorizationHandler, PermissionAuthorizationHandler>();

使用策略授权

那么,怎么在应用代码中使用基于权限的授权呢?

最为简单的,我们可以直接借助于 ASP.NET Core 的授权策略来实现基于权限的授权,因为此时并不需要资源。

services.AddAuthorization(options =>
{options.AddPolicy(Permissions.UserCreate, policy => policy.AddRequirements(new PermissionAuthorizationRequirement(Permissions.UserCreate)));options.AddPolicy(Permissions.UserRead, policy => policy.AddRequirements(new PermissionAuthorizationRequirement(Permissions.UserRead)));options.AddPolicy(Permissions.UserUpdate, policy => policy.AddRequirements(new PermissionAuthorizationRequirement(Permissions.UserUpdate)));options.AddPolicy(Permissions.UserDelete, policy => policy.AddRequirements(new PermissionAuthorizationRequirement(Permissions.UserDelete)));
});

如上,针对每一个权限项都定义一个对应的授权策略,然后,就可以在控制器中直接使用[Authorize]来完成授权:

[Authorize]public class UserController : Controller{[Authorize(Policy = Permissions.UserRead)]    public ActionResult Index()    {}[Authorize(Policy = Permissions.UserRead)]    public ActionResult Details(int? id)    {}[Authorize(Policy = Permissions.UserCreate)]    public ActionResult Create()    {        return View();}[Authorize(Policy = Permissions.UserCreate)][HttpPost][ValidateAntiForgeryToken]    public IActionResult Create([Bind("Title")] User user)    {}
}

当然,我们也可以像基于资源的授权那样,在应用代码中调用IAuthorizationService完成授权,这样做的好处是无需定义策略,但是,显然一个一个来定义策略太过于繁琐。

还有一种更好方式,就是使用MVC过滤器来完成对IAuthorizationService的调用,下面就来演示一下。

自定义授权过滤器

我们可以参考上一章中介绍的《AuthorizeFilter》来自定义一个权限过滤器:

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true, Inherited = true)]public class PermissionFilter : Attribute, IAsyncAuthorizationFilter{    public PermissionFilter(string name)    {Name = name;}    

public string Name { get; set; }  

public async Task OnAuthorizationAsync(AuthorizationFilterContext context)    {        var authorizationService = context.HttpContext.RequestServices.GetRequiredService<IAuthorizationService>();        var authorizationResult = await authorizationService.AuthorizeAsync(context.HttpContext.User, null, new PermissionAuthorizationRequirement(Name));        if (!authorizationResult.Succeeded){context.Result = new ForbidResult();}}
}

上面的实现非常简单,我们接受一个name参数,代表权限的名称,然后将权限名称转化为PermissionAuthorizationRequirement,最后直接调用 authorizationService 来完成授权。

接下来,我们就可以直接在控制器中使用PermissionFilter过滤器来完成基于权限的授权了:

[Authorize]public class UserController : Controller{[PermissionFilter(Permissions.UserRead)]    public ActionResult Index()    {         return View(_userStore.GetAll());}[PermissionFilter(Permissions.UserCreate)]    public ActionResult Create()    {}[PermissionFilter(Permissions.UserCreate)][HttpPost][ValidateAntiForgeryToken]    public IActionResult Create([Bind("Title")] User user)    {}[PermissionFilter(Permissions.UserUpdate)]    public IActionResult Edit(int? id)    {}[PermissionFilter(Permissions.UserUpdate)][HttpPost][ValidateAntiForgeryToken]    public IActionResult Edit(int id, [Bind("Id,Title")] User user)    {}
} 

在视图中使用授权

通常,在前端页面当中,我们也需要根据用户的权限来判断是否显示“添加”,“删除”等按钮,而不是让用户点击“添加”,再提示用户没有权限,这在 ASP.NET Core 中实现起来也非常简单。

我们可以直接在Razor视图中注入IAuthorizationService来检查用户权限:

@inject IAuthorizationService AuthorizationService@if ((await AuthorizationService.AuthorizeAsync(User, AuthorizationSample.Authorization.Permissions.UserCreate)).Succeeded)
{    <p><a asp-action="Create">创建</a></p>}

不过,上面的代码是通过策略名称来授权的,如果我们使用了上面创建的授权过滤器,而没有定义授权策略的话,需要使用如下方式来实现:

@inject IAuthorizationService AuthorizationService@if ((await AuthorizationService.AuthorizeAsync(User, new PermissionAuthorizationRequirement(AuthorizationSample.Authorization.Permissions.UserCreate))).Succeeded)
{    <p><a asp-action="Create">创建</a></p>}

我们也可以定义一个AuthorizationService的扩展方法,实现通过权限名称进行授权,这里就不再多说。

我们不能因为隐藏了操作按钮,就不在后端进行授权验证了,就像JS的验证一样,前端的验证就为了提升用户的体验,后端的验证在任何时候都是必不可少的。

总结

在大多数场景下,我们只需要使用授权策略就可以应对,而在授权策略不能满足我们的需求时,由于 ASP.NET Core 提供了一个统一的 IAuthorizationService 授权接口,这就使我们扩展起来也非常方便。ASP.NET Core 的授权部分到这来也就介绍完了,总的来说,要比ASP.NET 4.x的时候,简单,灵活很多,可见 ASP.NET Core 不仅仅是为了跨平台,而是为了适应现代应用程序的开发方式而做出的全新的设计,我们也应该用全新的思维去学习.NET Core,踏上时代的浪潮。

相关文章:

  • ASP.NET Core 认证与授权[4]:JwtBearer认证

  • ASP.NET Core 认证与授权[2]:Cookie认证

  • ASP.NET Core 认证与授权[3]:OAuth & OpenID Connect认证

  • Asp.Net Core 2.0 多角色权限认证

  • asp.net core 2.0 web api基于JWT自定义策略授权

  • ASP.NET Core 认证与授权[5]:初识授权

  • ASP.NET Core 认证与授权[6]:授权策略是怎么执行的?

原文:http://www.cnblogs.com/RainingNight/p/dynamic-authorization-in-asp-net-core.html


.NET社区新闻,深度好文,欢迎访问公众号文章汇总 http://www.csharpkit.com 

ASP.NET Core 认证与授权[7]:动态授权相关推荐

  1. ASP.NET Core 认证与授权[2]:Cookie认证

    ASP.NET Core 认证与授权[2]:Cookie认证 原文:ASP.NET Core 认证与授权[2]:Cookie认证 由于HTTP协议是无状态的,但对于认证来说,必然要通过一种机制来保存用 ...

  2. ASP.NET Core 认证与授权[6]:授权策略是怎么执行的?

    ASP.NET Core 认证与授权[6]:授权策略是怎么执行的? 原文:ASP.NET Core 认证与授权[6]:授权策略是怎么执行的? 在上一章中,详细介绍了 ASP.NET Core 中的授权 ...

  3. ASP.NET Core 认证与授权[5]:初识授权

    经过前面几章的姗姗学步,我们了解了在 ASP.NET Core 中是如何认证的,终于来到了授权阶段.在认证阶段我们通过用户令牌获取到用户的Claims,而授权便是对这些的Claims的验证,如:是否拥 ...

  4. ASP.NET Core 认证与授权[3]:OAuth OpenID Connect认证

    在上一章中,我们了解到,Cookie认证是一种本地认证方式,通常认证与授权都在同一个服务中,也可以使用Cookie共享的方式分开部署,但局限性较大,而如今随着微服务的流行,更加偏向于将以前的单体应用拆 ...

  5. ASP.NET Core 3.0中使用动态控制器路由

    原文:Dynamic controller routing in ASP.NET Core 3.0 作者:Filip W 译文:https://www.cnblogs.com/lwqlun/p/114 ...

  6. ASP.NET Core 认证与授权[1]:初识认证

    在ASP.NET 4.X 中,我们最常用的是Forms认证,它既可以用于局域网环境,也可用于互联网环境,有着非常广泛的使用.但是它很难进行扩展,更无法与第三方认证集成,因此,在 ASP.NET Cor ...

  7. ASP.NET Core 认证与授权[4]:JwtBearer认证

    Bearer认证 HTTP提供了一套标准的身份验证框架:服务器可以用来针对客户端的请求发送质询(challenge),客户端根据质询提供身份验证凭证.质询与应答的工作流程如下:服务器端向客户端返回40 ...

  8. asp.net core 认证及简单集群

    众所周知,在Asp.net WebAPI中,认证是通过AuthenticationFilter过滤器实现的,我们通常的做法是自定义AuthenticationFilter,实现认证逻辑,认证通过,继续 ...

  9. ASP.NET Core Identity 实战(4)授权过程

    这篇文章我们将一起来学习 Asp.Net Core 中的(注:这样描述不准确,稍后你会明白)授权过程 前情提要 在之前的文章里,我们有提到认证和授权是两个分开的过程,而且认证过程不属于Identity ...

最新文章

  1. Android UI系列-----CheckBox和RadioButton(1)
  2. css 文字过长 省略号,css实现文字过长显示省略号的方法
  3. 五连阳回调买入法_短线高手总结的强势股回调买入法,散户需牢记
  4. centos7下安装gcc7
  5. 模拟一次CSRF(跨站请求伪造)例子,适合新手
  6. 这个 CSS 库竟能帮你做汉堡?
  7. Go语言中Tcp协议粘包问题处理
  8. Python类常用的魔术方法
  9. 查看DLL中导出的函数及参数
  10. 实用机器人设计(一)-机器人技术基础
  11. cif t t操作流程图_cif流程(cif贸易术语流程图)
  12. python好找工作吗2017-2017年 Python工程师面试经历分享(七家)
  13. linux环境下gitea使用,linux一键安装gitea
  14. 分段函数求法(if和switch)
  15. PKU2069 Super Star 点集最小外接球
  16. 数字孪生开发公司 数字孪生开发团队 智慧工厂开发
  17. java gif转jpg_Java gif图片转换为jpg格式
  18. 苹果和虫子编程题python_2020智慧树《兽医寄生虫学》免费最全题库2020中国大学mooc《线性代数习题选讲》...
  19. pyinstaller打包三坑
  20. 微信公众号实现点击显示答案效果

热门文章

  1. 二 面向对象三大特性
  2. Pressed状态和clickable,duplicateParentState的关系
  3. bootstrap模态框
  4. Spring学习笔记十二---泛型依赖注入
  5. frame buffer编程--画点功能和新增字符串代替RGBT
  6. crontab定时任务中文乱码问题
  7. Memcached 缓存个体,对象,泛型,表
  8. android关于获取摄像头帧数据转成图片
  9. LoadPostData 的一些注意事项
  10. .NET 运行时设置