.NET Core中的认证治理剖析

0x00 题目泉源

在新建.NET Core的Web项目时挑选“运用个人用户账户”就能够建立一个带有用户和权限治理的项目，已预备好了用户注册、登录等许多页面，也能够运用AuthorizeAttribute举行种种权限治理，看起来好像非常轻易。不过生成的代码都替我干了些什么我一团雾水。看了下生成的数据表，功用也挺庞杂的。实际上我需要的只是基于用户和角色的认证治理，而且用户材料是运用现有的库，但运用.NET Core自带的认证组件必需要依靠EF，表的构造也许多对不上，所以进修了下自带的认证组件的完成，然后本身写了个认证效劳替换了Identity组件，同时Cookie治理运用自带的Cookie中间件、能够运用AuthorizeAttribute举行认证。庞杂的需求还没碰到，所以就进修到了这里。这篇博客主要议论最简朴情况下的的基于用户和角色的认证。关于.NET Core自带认证组件的一些基础用法，能够参考http://www.ki4.cn/。

0x01 .NET Core中的认证治理

提到认证治理，宰衡想到的就是用户的注册、登录、注销以及给用户增加/删除角色等功用。个中用户信息，角色信息等都是保留在数据库中的。所以主要包括数据库操纵和登录营业逻辑两部份。在登录营业逻辑层面，.NET Core主要经由历程三个比较中心的类UserManager、RoleManager、SigninManager举行治理（在Microsoft.AspNetCore.Identity顺序集）。个中：

UserManager主要担任用户的认证、注册、修正、删除以及与用户相干的角色、令牌、声明等的治理。
RoleManager担任角色、角色相干声明的治理。
SigninManager担任登录、注销等相干操纵。在触及到用户操纵（如上岸时用户考证）会挪用UserManager举行操纵。

这三个中心类在操纵数据库时，运用数据库层面的UserStore、RoleStore举行操纵（在Microsoft.AspNetCore.Identity.EntityFrameworkCore顺序集）。营业关联如下图所示：

我们在开辟认证相干功用时运用这三个中心类即可满足大多数需求。我们在运用这几个中心类的对象时都是经由历程依靠注入猎取的，那末这些相干的依靠是什么时刻注入的呢？在Startup的ConfigureServices要领中有AddIdentity扩大要领，就是在这个要领中增加了需要的一切依靠。

0x02 登录和注销

相识了Identity组件的团体分工后，再来看一下登录和注销的操纵的部份细节。登录和注销历程主要由SigninManager担任，的先来看一下登录的历程：

登录胜利后Response的Header中包括了Set-Cookie，Cookie的Key需要和Cookie中间件中设置的要解密的Cookie的Key一致，在截图中这个Cookie的Key是IdentityCookie。设置Cookie的同时返回302重定向到登录页面。

重定向到上岸页面时，要求中已带有设置的Key为IdentityCookie的Cookie了。

注销历程比较简朴，挪用HttpContext.Authentication.SignOutAsync要领即可注销，此时会给HttpContext.Response增加Set-Cookie，但内容为空。

0x03 经由历程Cookie辨认用户

.NET Core中经由历程CookieAuthenticationMiddleware这个中间件辨认HttpContext中认证相干的Cookie，从而增加用户的考证和受权信息。最症结的是ClaimsPrincipal对象，它纪录用户的认证和受权信息（除此之外固然也能够包括别的你需求的恣意信息），从上面登录历程能够看到，登录胜利后用户认证和受权信息保留至ClaimsPrincipal对象（实际上关于这条Cookie键值对中的认证信息保留为ClaimsIdentity，一个ClaimsPrincipal能够包括多个ClaimsIdentity），然后在HttpContext.Response的Headers中增加Set-Cookie，Key为Cookie中间件中指定的CookieName，Value就是这个对象加密后的字符串。今后的HttpContext都邑带有这个Cookie，Cookie中间件会把相符这个CookieName的Cookie取出来，解密并还原为ClaimsPrincipal对象，并把HttpContext.User设置为这个对象。背面MVC中间件在路由到响应Controller和Action的时刻就能够依据Authorize特征中指定的认证和角色在HttpContext.User中举行搜检，不满足搜检则跳转至响应页面。因而需要注重的就是肯定要把Cookie中间件放在MVC中间件之前。

这里需要特别说一下ClaimsPrincipal。一个ClaimsPrincipal对象中包括了一个或多个ClaimsIdentity对象，一个ClaimsIdentity对象一般来讲对应着一个Cookie中某条键值对（个人邃晓）。Cookie中间件和ClaimsIdentity是经由历程AuthenticationScheme联系起来的。背面我们在写本身的认证效劳时，也是把Cookie中间件的AuthenticationScheme和建立的ClaimsIdentity一致。所以更正确地说是ClaimsIdentity包括了用户认证和权限的声明，而ClaimsPrincipal能够包括多个ClaimsIdentity。当管道中存在多个Cookie中间件时，经由历程AuthenticationScheme举行辨别。

在ClaimsIdentity中除了AuthenticationScheme外另有两个比较主要的属性，UserType和RoleType，个中UserType指定了用户考证范例，RoleType指定可角色考证范例。意义就是假如我指定了RoleType为”RoleName”，那末在举行角色认证时就会寻觅Claims中一切的Type为”RoleName”的值，并搜检个中是不是包括了Authorize中指定的RoleName。不过.NET Core中自带了ClaimTypes，能够直接运用。比方角色范例就是ClaimTypes.Role。假如增加角色时用的自带的ClaimTypes.Role，那末在建立ClaimsIdentity时就不需要显现指定RoleType了，默许角色认证就是运用ClaimTypes.Role。

关于Cookie中间件的增加，是经由历程Startup中Configure要领中的app.UseIdentity扩大要领完成的。这个扩大要领实际上增加了多种Cookie辨认体式格局。在背面我在写本身的用户认证治理时只用一种。

0x04 本身写用户认证治理

相识了用户认证的历程，我们能够本身写认证治理来替代Identity组件了，一样分为数据库操纵和认证营业逻辑。数据库相干就不多说了，都写到了IdentityRepository类，只需很简朴的数据操纵。为了轻易运用了Dapper，数据库用的Sqlite。顺序在启动时会搜检数据库表，没有会自动建立空表。

认证效劳也比较简朴就都写到了IdentityService类，供应了注册和登录操纵，注销太简了直接写在了Action里。为了轻易没有供应角色治理页面，假如要测试角色认证功用，需要手动去数据库增加Role，然后在UserRoles中给用户增加Role。

注销：

只是为了测试，逻辑上许多题目，比方用户暗码明文存储。重点看历程:)

0x05 写在末了

第一次打仗Web运用，许多观点都不是很相识。就拿Cookie认证用户来讲，我之前的只晓得经由历程Cookie辨认用户，一向以为是收到Cookie后再从数据库或缓存中查出响应的权限信息。不过看了自带的Cookie中间件代码后才晓得认证信息是直接存在Cookie中的，如许只需解密后反序列化就能够了。Identity这个顺序集触及了许多别的顺序集（Security、HttpAbstraction等等），看得我很晕，末了总算搞邃晓了一些，许多细节也没去穷究，文中内容有的基于代码，有的基于个人邃晓，有毛病愿望人人嘴下包涵。

以上就是.NET Core认证治理剖析的细致内容，更多请关注ki4网别的相干文章！