前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >.Net Core 授权组件源码解析

.Net Core 授权组件源码解析

作者头像
郑小超.
发布2019-12-30 17:32:15
9510
发布2019-12-30 17:32:15
举报
文章被收录于专栏:GreenLeavesGreenLeaves

前面关于.Net Core如何进行用户认证的核心流程介绍完毕之后,.Net Core 认证系统之Cookie认证源码解析远程认证暂时不介绍,后期有时间,我会加上.接下去介绍认证组件是如何和认证组件一起协同工作.源码的路径如下,自行去github下载.ok,开始!

1、认证组件的执行流程

Core启动认证组件的方式很简单.

和认证系统一样,都是以中间件的形式提供服务.

验证有没有注入授权组件的核心服务.

接下去查看中间件的代码,如下:

校验过程就不说了,第一步:

从终结点元数据中读取打了Authorize的特性的控制器和方法.那么意味这此时控制器已经被注入了,所以一般services.AddMvc()和add.UseMvc()是先于认证组件注入的.

且微软提示,如果你自定义了一个授权Filter,改变了认证逻辑,可能会造成错误,不建议这种方式.因为核心认证组件支持所有的业务扩展,没必要再去定义额外的Filter.

接着看如下代码:

AuthorizationPolicy类合并了需要认证的元数据和认证策略提供类.那去找找IAuthorizationPolicyProvider接口的实现,如下

在注入服务的时候,微软注入了默认的实现,又是Provider模式,Core底层大量采用了这个模式,所以如果你不知道,先去补补设计模式的知识点,可以参考本人的设计模式分类.这个设计模式很简单.不看代码就能猜出大致的实现,内部肯定维护了一个键值对,Dic或者HashMap.那就去看看.

调用了AuthorizationOptions参数中的GetPolicy方法,对应

果然是个字典.这意味这我们可以通过认证参数来配置认证策略,添加策略的方法如下:

ok,再去看看AuthorizationPolicy的构造,其维护了两个主要的属性,后面会介绍.

一个认证方案的名称和一个授权条件集合,到这里可以知道认证组件可以和授权组件集成到一起使用的结论.

讲到这,回到中间件

_prolicyProvider提供的是认证方案的名称和授权条件集合,以及需要被认证的元数据集合.

接着,看看AuthorizationPolicy.CombineAsync的实现

跳过参数校验,分析核心代码,第一步:

遍历需要授权的元数据集合

AuthorizationPolicyBuilder,授权策略Buidler生成器,负责生成授权策略。Buidler生成器模式,不懂其移步本人设计模式分类,很简单.

判断需要授权元数据的Policy属性,ok,到这里.很明显.我们得看看Authorize特性

这个时候

红框里得值就为"自定义授权策略",接着通过policyProvider拿到对应得AuthorizationPolicy实例,本质就是认证策略名称为"自定义授权策略"的认证方案和授权条件集合.

接着通过policyBuilder将认证策略名称为"自定义授权策略"的认证方案和授权条件集合.

添加到AuthorizationPolicyBuilder实例的下面两个属性中去

此时,当你这样设置控制器或者其下的方法

说明你不在采用授权组件的默认策略,所以

接着

又去判断当前需要授权元数据的Authorize特性中是否设置了Roles特性,且可以设置多个,以","分隔

到这里说明自定义策略授权和Role授权是可以共存的,可以向下面这样

接着

这个方法本质,就是向AuthorizationPolicyBuilder实例的

追加授权条件.

简单说下为什么微软要给授权组件预留Roles角色集合,因为当前市面上主流的权限设计系统都是RBAC模式,中文就是基于角色(Role)的权限管理系统.

接着

这里和角色一样不介绍了

到这里你会发现 基于认证方案授权策略+基于角色的授权策略=自定义策略的授权策略.

接着,如果没有任何控制器或者方法使用授权策略,那么使用最基本的拒绝匿名访问api策略

核心代码如下:

如果当前用户未认证,则不能访问.

当然这个策略也可以通过AuthorizationOptions参数进行重写.

最后

去重构建一个新的PolicyBuilder对象实例.

接着

执行PolicyBuilder中的用户认证,其中做了一些重复登陆的处理.本质就是如此.

这段代码就可以看出.如果当前用户未登陆,则返回

接着回到中间件

认证完毕之后,如果当前元数据打了AllowAnonymous特性像下面这样

执行下一个中间件.但是上面的认证操作会做.

最后

调用授权服务,进行授权校验.默认的授权服务注入点如下:

构建授权上下文,接着拿到所有的授权处理器.遍历执行

这个参数,可配置,当一个授权策略校验失败,便不再执行接下去的授权策略.

最后返回授权结果

总结:本质就是将

特性中的这两个参数,交给IAuthorizationHandler授权处理器处理.当然如果你制定了认证方案,那么则会去判断当前用户是否登陆.

整个流程结束.纯属个人理解,能力有限,有问题,请指正,谢谢.

接下去会写一篇动态授权的文章,这样就能将授权组件+认证组件+权限系统集合起来实现完成用户认证和api动态授权.为后期的前端后端分离架构-基于id4的password模式+JwtBear认证+identity的授权认证中心做准备.最后形成一个完整的授权认证中心.

g

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2019-12-25 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
消息队列 TDMQ
消息队列 TDMQ (Tencent Distributed Message Queue)是腾讯基于 Apache Pulsar 自研的一个云原生消息中间件系列,其中包含兼容Pulsar、RabbitMQ、RocketMQ 等协议的消息队列子产品,得益于其底层计算与存储分离的架构,TDMQ 具备良好的弹性伸缩以及故障恢复能力。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档