ASP NET Core 之 Identity 入门.docx

ASP NET Core 之 Identity 入门.docx

《ASP NET Core 之 Identity 入门.docx》由会员分享，可在线阅读，更多相关《ASP NET Core 之 Identity 入门.docx（12页珍藏版）》请在冰豆网上搜索。

ASPNETCore之Identity入门

ASP.NETCore之Identity入门

前言

在ASP.NETCore中，仍然沿用了ASP.NET里面的Identity组件库，负责对用户的身份进行认证，总体来说的话，没有MVC5里面那么复杂，因为在MVC5里面引入了OWIN的东西，所以很多初学者在学习来很费劲，对于Identity都是一头雾水，包括我也是，曾经在学identity这个东西前后花了一个多月来搞懂里面的原理。

所以大部分开发者对于Identity并没有爱，也并没有使用它，会觉得被绑架。

值得庆幸的是，在ASP.NETCore中，由于对模块的抽象化逐渐清晰，以及中间件的使用，这使得Identity的学习和使用路线变得更加平易近人，下面就让我们一起来看看吧。

GettingStarted

在开始之前，让我们先忘记它和EntityFramework的关系，也忘记它和Authentication的关系，我们先学习几个英语单词。

有这么几个“单词”你可能需要弄明白：

#1：

Claims

大家应该都知道身份证长什么样子的，如下：

其中，姓名：

奥巴马；性别：

男；民族：

肯尼亚；出生：

1961.08.04，等等这些身份信息，可以看出都是一个一个的键值对，那如果我们想在程序中存这些东西，怎么样来设计呢？

对，你可能想到了使用一个字典进行存储，一个Key，一个Value刚好满足需求。

但是Key，Value的话感觉不太友好，不太面向对象，所以如果我们做成一个对象的话，是不是更好一些呢？

最起码你可以用vs的智能提示了吧，我们修改一下，改成下面这样：

//我给对象取一个名字叫`Claim`你没有意见吧

publicclassClaim

{

publicstringClaimType{get;set;}

publicstringClaimValue{get;set;}

}

ClaimType就是Key，ClaimValue就代表一个Value。

这样的话，刚好可以存储一个键值对。

这时候姓名：

奥巴马是不是可以存进去了。

微软的人很贴心，给我们准备了一些默认的ClaimType呢？

很多常用的都在里面呢，一起看看吧：

这里延伸第一个知识点：

ClaimTypes

为了阅读体验，截图我只放了一部分哦。

可以看到有什么Name，Email，Gender，MobilePhone等常用的都已经有了，其他的还有很多。

细心的读者可能注意了，它的命名空间是System.Security.Claims，那就说明这个东西是.net框架的一部分，嗯，我们暂时只需要知道这么多就OK了。

Claim介绍完毕，是不是很简单，其他地方怎么翻译我不管，在本篇文章里面，它叫“证件单元”。

#2：

ClaimsIdentity

在有了“证件单元”之后，我们就用它可以制造一张身份证了，那么应该怎么样制造呢？

有些同学可能已经想到了，对，就是新建一个对象，然后在构造函数里面把身份证单元传输进去，然后就得到一张身份证了。

我们给这张身份证取一个英文名字叫“ClaimsIdentity”，这个名字看起来还蛮符合的，既有Claims表示其组成部分，又有表示其用途的Identity（身份），很满意的一个名字。

实际上，在现实生活中，我们的身份证有一部分信息是隐藏的，有一部分是可以直接看到的。

比如新一代的身份证里面存储了你的指纹信息你是看不到的，这些都存储在身份证里面的芯片中，那能看到的比如姓名啊，年龄啊等。

我们在设计一个对象的时候也是一样，需要暴露出来一些东西，那这里我们的ClaimsIdentity就暴露出来一个Name，Lable等。

我们造的身份证（ClaimsIdentity）还有一个重要的属性就是类型（AuthenticationType），等等，AuthenticationType是什么东西？

看起来有点眼熟的样子。

我们知道我们自己的身份证是干嘛的吧，就是用来证明我们的身份的，在你证明身份出示它的时候，其实它有很多种形式载体的，什么意思呢？

比如你可以直接拿出实体形式的身份证，那也可以是纸张形式的复印件，也可以是电子形式的电子码等等，这个时候就需要有一个能够表示其存在形式的类型字段，对，这个AuthenticationType就是干这个事情的。

然后我们在给我们的身份证添加一些润色，让其看起来好看，比如提供一些方法添加Claims的，删除Claims的，写到二进制流里面的啊等等，最终我们的身份证对象看起来基本上是这样了：

publicclassClaimsIdentity

{

publicClaimsIdentity（IEnumerableclaims）{}

//名字这么重要，当然不能让别人随便改啊，所以我不许set，除了我儿子跟我姓，所以是virtual的

publicvirtualstringName{get;}

publicstringLabel{get;set;}

//这是我的证件类型，也很重要，同样不许set

publicvirtualstringAuthenticationType{get;}

publicvirtualvoidAddClaim（Claimclaim）;

publicvirtualvoidRemoveClaim（Claimclaim）;

publicvirtualvoidFindClaim（Claimclaim）;

}

嗯，到这里，我们的身份证看起来似乎很完美了，但是从面向对象的角度来说好像还少了点什么东西？

对~，还是抽象，我们需要抽象出来一个接口来进行一些约束，约束什么呢？

既然作为一个证件，那么肯定会涉及到这几个属性信息：

1、名字。

2、类型。

3、证件是否合法。

反应到接口里面的话就是如下，我们给接口取个名字叫：

“身份（IIdentity）”：

这里延伸第二个知识点：

IIdentity接口。

//定义证件对象的基本功能。

publicinterfaceIIdentity

{

//证件名称

stringName{get;}

//用于标识证件的载体类型。

stringAuthenticationType{get;}

//是否是合法的证件。

boolIsAuthenticated{get;}

}

所以我们的ClaimsIdentity最终看起来定义就是这样的了：

publicclassClaimsIdentity:

IIdentity

{

//......

}

ClaimsIdentity介绍完毕，是不是发现也很简单，其他地方怎么翻译我不管，在本篇文章里面，它叫“身份证”。

#3：

ClaimsPrincipal

有了身份证，我们就能证明我就是我了，有些时候一个人有很多张身份证，你猜这个人是干嘛的？

对，不是黄牛就是诈骗犯。

但是，有些时候一个人还有其他很多种身份，你猜这个人是干嘛的？

这就很正常了对不对，比如你可以同时是一名教师，母亲，商人。

如果你想证明你同时有这几种身份的时候，你可能需要出示教师证，你孩子的出生证，法人代表的营业执照证。

在程序中，一个身份证不仅仅代表你这个人了，而是代表一个身份，是证明你自己的主要身份哦。

如果一个人还有其他很多种身份，这个时候就需要有一个东西（载体）来携带着这些证件了对吧？

OK，我们给需要携带证件的这个对象取一个贴切点的名字，叫“证件当事人（ClaimsPrincipal）”吧。

以下是Principal这个单词在词典给出的解释，我用它你应该没意见吧：

principal['prɪnsəpl]

adj.主要的；资本的

n.首长；校长；资本；当事人

这个时候可能有同学会问了，是不是应该叫ClaimsIdentityPrincipal比较好呢？

嗯，我也觉得应该叫ClaimsIdentityPrincipal可能更好一点，或许微软的人偷懒了，简写成了ClaimsPrincipal。

知道其功能后，代码就很好写了，和上面ClaimsIdentity一样的套路：

publicclassClaimsPrincipal

{

//把拥有的证件都给当事人

publicClaimsPrincipal（IEnumerableidentities）{}

//当事人的主身份呢

publicvirtualIIdentityIdentity{get;}

publicvirtualIEnumerableIdentities{get;}

publicvirtualvoidAddIdentity（ClaimsIdentityidentity）;

//为什么没有RemoveIdentity，留给大家思考吧？

}

当时人看起来也几乎完美了，但是我们还需要对其抽象一下，抽象哪些东西呢？

作为一个当事人，你应该有一个主身份吧，就是你的身份证咯，可能你还会用到角色（角色后面会详细介绍，这里你知道有这么个东西就行了）。

这里延伸第三个知识点：

IPrincipal接口。

publicinterfaceIPrincipal

{

//身份

IIdentityIdentity{get;}

//在否属于某个角色

boolIsInRole（stringrole）;

}

然后，我们的证件当事人看起来应该是这样的：

publicclassClaimsPrincipal:

IPrincipal

{

//...

}

ClaimsPrincipal介绍完了，也很简单吧？

其他地方怎么翻译我不管，在本篇文章里面，它叫“证件当事人”。

想在，我们已经知道了“证件单元（Claims）”，“身份证（ClaimsIdentity）”，“证件当事人（ClaimsPrincipal）”，并且整理清楚了他们之间的逻辑关系，趁热打铁，下面这个图是一个identity登入部分的不完全示意图，虚线圈出来的部分应该可以看懂了吧：

可以看出，首先我们在app这边有一些证件单元，然后调用ClaimsIdentity把证件单元初始化为一个身份证，然后再把身份证交给证件当事人由其保管。

才把GettingStarted写完，发现已经这么长了，所以打算写成一个系列了，可能3-4篇吧。

总结

好了，本篇就先介绍到这里，在本篇博客中，我们学会了几个英文单词，并且知道了这些英文单词在程序中是扮演这怎么样一个对象。

并且根据图我们知道了这些对象在整个认证系统种处在怎么样一个位置。

我发现如果想把identity讲清楚仅仅靠这一篇博客是不够的，下一篇我们将对.NETAuthentication中间件进行抽丝剥茧，直到掌握.NET的整个认证系统后，我们再来看一下Identiy到底和EntityFramework有着怎样的爱恨情仇。

这仅仅是一个开始，大家如果觉得本篇博客对您有帮助的话，感谢您的【推荐】，如果你对.NETCore感兴趣可以关注我，我会定期在博客分享关于.NETCore的学习心得。

在上篇文章中讲了关于Identity需要了解的单词以及相对应的几个知识点，并且知道了Identity处在整个登入流程中的位置，本篇主要是在.NET整个认证系统中比较重要的一个环节，就是认证（Authentication），因为想要把Identity讲清楚，是绕不过Authentication的。

在之前写过一篇关于ASP.NETCore中间件的文章，里面有一部分（怎么样自定义自己的中间件）是具体关于认证系统的一个具体使用，有兴趣的朋友可以看一下这篇文章。

其实Identity也是认证系统的一个具体使用，大家一定要把Authentication和Identity当作是两个东西，一旦混淆，你就容易陷入进去。

下面就来说一下ASP.NETCore中的认证系统是怎么样一回事。

不要怕，其实很简单，全是干货~

GettingStarted

大家应该还记得在上一篇中的奥巴马先生吧，他现在不住在华盛顿了，他到中国来旅游了，现在住在北京，这几天听说西湖风景不错，于是在12306定了一张北京到杭州的高铁票。

取到票之后，他向我们展示了一下：

今天是11.11号，奥巴马很开心，原因你懂的。

快到出发的时间了，于是，拿着票走到了火车站检票口，刚把身份证和火车票递给检票员。

“cut”，导演喊了一声。

尼玛原来是在拍电影呢~

导演说：

奥巴马，你演的太烂了，别演了，你来演检票员吧，让旁边小李来演要出行路由的奥巴马吧。

奥巴马不情愿的说了一声：

“好吧，希望小李能够受的了你”。

“action”，导演又喊了一声，故事开始了~

AuthenticationManager

奥巴马当了检票员以后，特别高兴，因为他有权利了呀，他可以控制别人能不能上车了，说不定还能偷偷放几个人进去捞点外快呢。

得知了他能干什么以后，他觉得检票员这个名字简直太low了，很快，他就有了一个新的高大上的名字，叫：

认证管理员（AuthenticationManager），而且，他觉得他自己应该处在整个核心位置，为什么呢？

你想想看，那么庞大的一套铁路载人系统，能不能有收入有钱赚，全靠他给不给放人进去，如果一个人都不放进去，另外那一大帮人只能去喝西北风了。

到这里，聪明的同学可能已经知道奥巴马把他自己放在怎么样一个核心位置了。

对，他把自己放到了HttpContext里面。

怎么样？

够核心吧。

这里延伸第一个知识点：

AuthenticationManager所处的位置

有同学在上面的截图里面发现了publicabstractClaimsPrincipalUser{get;set;}，这不就是我们上一篇中讲到的“证件当事人”，现在小李扮演的那个角色么？

对，这个User就是本文中的小李，被你提前发现他躲着这里了，嘿嘿。

还有一个知识点，就是AuthenticationScheme，什么意思呢？

且看

奥巴马敢把自己放在这么核心的位置也是有他的能力的，怎么讲呢？

比如说在检票的时候，别人递过来一张身份证和一张火车票，那怎么样验证这两个证件是合法的呢？

以下就是奥巴马提出的针对两种证件的验证方案：

方案1、针对身份证的验证，可以查看其本人是否和身份证头像是否一致，年龄是否符合当事人具体年龄。

方案2、针对火车票的验证，可以看车次，时间是否符合发车目标，另外可以看车票上的身份号码是否和身份证一致。

其中，这每一种方案，就对应一个AuthenticationScheme（验证方案名称），是不是明白了。

这就是第二个知识点AuthenticationScheme很重要。

知道了奥巴马的职责后，就很容易的把代码写出来了：

publicabstractclassAuthenticationManager

{

//AuthenticateContext包含了需要认证的上下文，里面就有小李

publicabstractTaskAuthenticateAsync（AuthenticateContextcontext）;

//握手

publicabstractTaskChallengeAsync（stringauthenticationScheme,AuthenticationPropertiesproperties,ChallengeBehaviorbehavior）;

//登入

publicabstractTaskSignInAsync（stringauthenticationScheme,ClaimsPrincipalprincipal,AuthenticationPropertiesproperties）;

//登出

publicabstractTaskSignOutAsync（stringauthenticationScheme,AtionPropertiesproperties）;

}

奥巴马做为一个检票员，有一个认证方法，AuthenticateAsync（），注意这是其一个核心功能，其他几个都可以没有，但是唯独不能没有这个功能，没有的话他就不能称之为一个检票员了。

然后还有一个握手ChallengeAsync，登入SignInAsync和登出SignOutAsync，下面说说笔者对这三个方法的理解吧。

ChallengeAsync：

是社区协议文件RFC2167定义的关于在HTTPAuthentication过程中的一种关于握手的一个过程，主要是摘要认证（digestauthentication），更多信息查看这里。

是不是有点专业，看不懂，没事，有通俗版本的。

小李要进站了，这个时候小李问了一下我们的检票员奥巴马先生。

小李：

“你好，检票员，我可以进站吗？

”

检票员奥巴马：

“要赶火车吗？

可以啊，请出示你的证件？

”

小李：

“好的，这是我的证件，你检查一下？

”

检票员奥巴马：

“嗯，证件没问题，进去吧”

这样一个过程就是握手（digest-challenge）或者叫问答的一个过程，明白了ChallengeAsync的原理了吧?

是不是很简单。

SignInAsync，SignOutAsync：

个人觉得这两个不应该放在这里，因为并不属于认证的职责，也不属于协议规定的内容。

但是这两个方法确实需要抽象，应该单独抽取一个接口存放，至于为什么这样做，或许是因为以下原因：

1、对登入登出的抽象是和认证紧密结合的，大多数情况下认证资料的保存是需要在SignIn进行的，比如CookiesAuthentication中间件就在SignIn方法里面做了Cookie的保存。

2、AuthenticationManager这个对象是处在HttpContext

上下文里面的，本着面向抽象和封装的原则，放到其里面是合适的，这样能够很方便的用户对其调用。

关于AuthenticationManager已经介绍完了，是不是很简单呢？

IAuthenticationHandler

有些同学可能会问了，如果AuthenticationManager不提供接口的话，只是一个抽象类的话，那如果自定义认证方法就必须继承它，这对于开发者来说是不友好的，也违背了面向接口编程的理念。

嗯，确实是这样，那么接口来了：

publicinterfaceIAuthenticationHandler

{

voidGetDescriptions（DescribeSchemesContextcontext）;

TaskAuthenticateAsync（AuthenticateContextcontext）;

TaskChallengeAsync（ChallengeContextcontext）;

TaskSignInAsync（SignInContextcontext）;

TaskSignOutAsync（SignOutContextcontext）;

}

这个接口是在AuthenticationManager实现类DefaultAuthenticationManager中延伸出来的，所以大家不用再去看里面的源码了，记住以后如果需要重写认证相关的东西，实现IAtionHandler就可以了。

Authentication中间件

对IAuthenticationHandler的初步实现，封装了AuthenticationHandler这个抽象类，把具体的核心功能都交给下游去实现了，下面的CookieAuthentication中间件核心类CookieAuthenticationHandler就是继承自AuthenticationHandler，知道这么多就够了。

CookieAuthentication中间件

故事还要继续，奥巴马在接到小李递来的身份证和火车票之后，首先拿着火车票在一个二维码机器上扫描了一下，然后又拿着身份证在一个机器上刷了一下，经过核查，发现都没有问题。

于是拿起印章在上面盖了一个“验讫”。

这中间都发生了什么呢？

首先，在二维码扫描的过程，这个过程二维码机器会解析你火车票上的二维码，如果发现解析失败，会直接响应认证失败。

也就是你别想进站了。

如果解析成功，就会得到你这个票据中的信息了，然后拿到你票据里面的的当事人信息进行验证是否被列为了铁路局黑名单中。

如果验证通过，则会给你颁发一个识别码，把符合你身份的一个识别码写入到你的火车票中和检票员旁边的电脑系统中，即“验讫”。

话说这个验讫有点高级，它会向你的火车票芯片中写入一些信息，那么都写入些什么信息呢？

1、奥巴马个人的信息。

2、验证途中的一些上下信息。

3、使用的验证方案。

知道了，这些之后，那么就很容易实现这个验证方法了，对吧？

以下是CookieAuthentication中间件中的核心类CookieAuthenticationHandler的里面的核心方法HandleAuthenticateAsync（），同样你可以理解为实现的IAuthenticationHandler接口的AuthenticateAsync：

protectedoverrideasyncTaskHandleAuthenticateAsync（）

{

//解析二维码

varresult=awaitEnsureCookieTicket（）;

if（!

result.Succeeded）

{

returnresult;

}

//从二维码中拿当事人信息进行验证

varcontext=newCookieValidatePrincipalContext（Context,result.Ticket,Options）;

awaitOptions.Events.ValidatePrincipal（context）;

if（context.Principal==null）

{

returnAuthenticateResult.Fail（"Noprincipal."）;

}

if（context.ShouldRenew）

{

RequestRefresh（result.Ticket）;

}

//验讫，写入芯片

returnAuthenticateResult.Success（newAuthenticationTicket（context.Principal,context.Properties,Options.AuthenticationScheme））;

}

HandleSignInAsync

我们故事继续……

奥巴马检票完成之后，把票就交给了小李，小李拿到票之后，导演又喊了一声：

“cut”……

怎么又停了，小李和奥巴马一肚子的疑