.Net Core certification system source code parsing

       Unconsciously .Net 3.1 Core has been introduced to, and most with .Net technology stack as companies have begun to gradually switch to turn the Core or Java, practitioners also faster than three years, has always insisted on. No matter how the environment changes, stick to their original choice, adhere to the faith .Net Core is a very good framework, if you are from WebForm start, step by step up to today, will naturally find Microsoft slowly began assembly of the entire frame, not like before that, so things are a fool, such as WebForm, mop scalable control can often get most of the things .Core well, will give ourselves a lot of choice, rather than a force for us to accept him that sets, good compatibility with third-party components. in other words, many of the core components of Microsoft offers a high level of abstraction, if you want to change, may not want to change, you can also use his default implementation. other advantages and disadvantages of not anything in detail, nor is the focus of this article. If time permits, we can recommend in-depth study of the underlying .Net Core.

1 Introduction

Eliminating the previous Core Web project to create a series of operations .VS help you automate all basic components are initialized, the environment. The first step is certification is landing. Of course, Microsoft provides a set of landing components. Very full, very perfect. Core source project 

 Under Security folder, download the source code itself to github. Which provides several authentication methods, common Cookie certification, JwtBear certification, etc. Also included FaceBook, Google and other remote authentication.

This article is temporarily not explain the specific authentication, mainly on core certification process.

 

Execution process (1), the authentication system

Core boot authentication system is very simple

 

 Very simple piece of code to see what it did

 

 Very simple, injection certified middleware, about middleware here is not that much, is not the focus of the text, on their own Baidu. See what the central parity did.

 

 Core code, the authentication process is first to get implanted in DI request processor set, then the program to acquire DI handling authentication scheme set authentication process request context. Context of the authentication request processing scheme to get the next set of processor authentication request corresponding to a class processor, the processor then performs HandleRequestAsync method, the authentication request completion processing context. this means that our request authentication parameters can be made our special treatment.

 

Adhesive

 

 处理完认证请求参数之后,接着去认证方案中拿到默认的认证方案,不为空,执行上下文的扩展方法context.AuthenticateAsync,这个方法干了什么如下:

 

 执行DI中注入的认证服务方法,并传入上下文和默认的认证方案名称.

 

 先判断存不存在默认认证方案,不存在抛异常,接着去所有的认证处理器集合中拿到默认认证方案的处理器.接着调用处理的认证方法,认证成功,判断当前用户身份集合中在临时缓存中存不存在,不存在,可以执行Claim的转换.这很好,说明用户认证成功之后的Cliam也是可以被转换的.

 

 只要注入IClaimsTransformation服务即可,你就可以执行你需要的业务的Claim转换,最后返回结果

 到这里整个认证流程结束.非常的简单.且关键点的扩展微软都预留了.可以自定义实现

 

(2)、流转服务的介绍.

上面介绍了整个认证组件的流转过程,因为我对流程很清楚,所以大家可能还是不理解.所以接下去开始介绍流转必须服务的注入.

 认证处理器的Provider类,那么Core实在哪里注入认证处理器的呢?

 

 这里,核心也是红框里的,下面的只是一些依赖组件。

 

 微软注入默认的认证处理器.看下获取处理器的实现,对应中间件.

 

 阅读源码发现,Provider类并不具体实现提供认证处理器的方法.而是通过SchemeProvider来提供.

 

原来是IAuthenticationSchemeProvider类提供认证处理器.而且是通过反射实现(这点开销,就没必要考虑性能问题,当然你可以考虑重构),那么问题来了,在哪里出入IAuthenticationSchemeProvider服务内,回到上面那张图

 

 微软也提供了默认实现,去看看GetSchemeAsync方法的实现

 

 

 ok,到这里就说明认证处理器通过向这个字典写入值,来实现的.也就是微软认证方案提供了认证处理器.

 

 上面是认证方案的核心字段,HandlerType就是认证处理器.

AuthenticationSchemeProvider类维护了一个_schemes的字典,通过它向外输出.认证方案集合提供类.

 接着认证处理器集合提供类AuthenticationHandlerProvider通过解析

认证方案集合提供类,拿到所有的认证处理器.

到这里,很明显,所有的认证处理器都是通过向AuthenticationSchemeProvider的_schemes字典注入认证处理器.既然如此,入口在哪?在AuthenticationBuilder类下面.

 下面是Cookie认证方式注入认证处理器的方式

 AddScmeme方法.在配置参数的同时,指定了处理器.

 

 接着,回到中间件的图

 我们通过AuthenticationBuilder的AddScheme方法向_schemes集合写入了认证处理器且配置了处理器的参数,接着通过AuthenticationHandlerProvider拿到了所有的认证处理器.

接着我们通过Schemes方案集合拿到所有处理认证请求上下文的处理器,执行处理认证请求上下文参数.处理完毕.

 

接着我们解析Schemes中提供的默认认证方案,代码如下:

 根据

 这个配置参数,一般在入口注入:

 中配置默认方案名称,拿到默认认证方案.再将处理过的认证请求上下文和默认方案传给IAuthenticationService,这个Service也有默认实现,如下:

 

 AuthenticationService将处理过的认证请求上下文交给具体的认证请求处理器来处理.并返回处理结果.认证请求处理器前面说过了,通过AuthenticationBuilder的AddScheme方法来注入.

到这里,整个组件的流程介绍结束.纯属个人理解,能力有限,有问题,请指正,谢谢.

下面开始介绍基于Cookie的认证组件.

 

Guess you like

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