.Net Core authorization system component parses .Net Cookie Core certification system of certification parsing source code

After the front on how to perform user authentication .Net Core core processes introductions, .Net Core Cookie authentication source authentication systems to resolve remote authentication temporarily introduced, the late time, I would add. Next is how to introduce certification and authentication components assembly with cooperative work follows the source path, github to download their own. OK, start!

1, the authentication component of the implementation process

Core components of the authentication start very simple way.

 

 And certification system, we are providing services in the form of middleware.

 Verify that there is no injection of core services authorized components. 

View next middleware code, as follows:

 

 

 

 Verification process is not to say, the first step:

 Reading metadata from the endpoint controller and method of playing characteristics of Authorize. At this time it means that the controller has been injected, it is generally services.AddMvc () and add.UseMvc () is the authentication component prior to implantation of.

And Microsoft suggests that if you customize an authorization Filter, change the authentication logic may cause an error, do not recommend this approach. Because the core authentication component supports all business expansion, no need to go to define additional Filter.

Then look at the following code:

 AuthorizationPolicy class incorporates metadata required certification and authentication policies provide class. IAuthorizationPolicyProvider achieve that look to find the interface, as follows

 When injected into the service, Microsoft into a default implementation, but also the Provider mode, Core underlying this model uses a lot, so if you do not know, go to replenish knowledge of design patterns, design patterns can refer to my classification. this design pattern is very simple. do not look at the code will be able to achieve a rough guess, inside certainly maintains a key-value pair, Dic or HashMap. then go and see.

 

 Method calls GetPolicy AuthorizationOptions parameters corresponding

 It really is a dictionary that means we can configure authentication policy through authentication parameters, add the policy as follows:

 ok, go look AuthorizationPolicy structure, which maintains two main attributes will be introduced later.

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

讲到这,回到中间件

 _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

Guess you like

Origin www.cnblogs.com/GreenLeaves/p/12099760.html