https://www.cnblogs.com/fish-li/archive/2012/04/15/2450571.html
用户登录是个很常见的业务需求，在ASP.NET中，这个过程被称为身份认证。 由于很常见，因此，我认为把这块内容整理出来，与大家分享应该是件有意义的事。
在开发ASP.NET项目中，我们最常用的是Forms认证，也叫【表单认证】。 这种认证方式既可以用于局域网环境，也可用于互联网环境，因此，它有着非常广泛的使用。 这篇博客主要讨论的话题是：ASP.NET Forms 身份认证。
有一点我要申明一下：在这篇博客中，不会涉及ASP.NET的登录系列控件以及membership的相关话题， 我只想用比较原始的方式来说明在ASP.NET中是如何实现身份认证的过程。
ASP.NET身份认证基础
在开始今天的博客之前，我想有二个最基础的问题首先要明确：
1. 如何判断当前请求是一个已登录用户发起的？
2. 如何获取当前登录用户的登录名？
在标准的ASP.NET身份认证方式中，上面二个问题的答案是：
1. 如果Request.IsAuthenticated为true，则表示是一个已登录用户。
2. 如果是一个已登录用户，访问HttpContext.User.Identity.Name可获取登录名（都是实例属性）。
接下来，本文将会围绕上面二个问题展开，请继续阅读。
ASP.NET身份认证过程
在ASP.NET中，整个身份认证的过程其实可分为二个阶段：认证与授权。
1. 认证阶段：识别当前请求的用户是不是一个可识别（的已登录）用户。
2. 授权阶段：是否允许当前请求访问指定的资源。
这二个阶段在ASP.NET管线中分别用AuthenticateRequest和AuthorizeRequest事件来表示。
在认证阶段，ASP.NET会检查当前请求，根据web.config设置的认证方式，尝试构造HttpContext.User对象供我们在后续的处理中使用。
在授权阶段，会检查当前请求所访问的资源是否允许访问，因为有些受保护的页面资源可能要求特定的用户或者用户组才能访问。
所以，即使是一个已登录用户，也有可能会不能访问某些页面。 当发现用户不能访问某个页面资源时，ASP.NET会将请求重定向到登录页面。
受保护的页面与登录页面我们都可以在web.config中指定，具体方法可参考后文。
在ASP.NET中，Forms认证是由FormsAuthenticationModule实现的，URL的授权检查是由UrlAuthorizationModule实现的。
如何实现登录与注销
前面我介绍了可以使用Request.IsAuthenticated来判断当前用户是不是一个已登录用户，那么这一过程又是如何实现的呢？
为了回答这个问题，我准备了一个简单的示例页面，代码如下：
<fieldset><legend>用户状态</legend><form action="<%= Request.RawUrl %>" method="post">
<% if( Request.IsAuthenticated ) { %>
当前用户已登录，登录名：<%= Context.User.Identity.Name.HtmlEncode() %> <br />
<input type="submit" name="Logon" value="退出" />
<% } else { %>
<b>当前用户还未登录。</b>
<% } %>
</form></fieldset>
页面显示效果如下：
写到这里，我想有必要再来总结一下在ASP.NET中实现登录与注销的方法：
1. 登录：调用FormsAuthentication.SetAuthCookie()方法，传递一个登录名即可。
2. 注销：调用FormsAuthentication.SignOut()方法。
保护受限制的页面
在一个ASP.NET网站中，有些页面会允许所有用户访问，包括一些未登录用户，但有些页面则必须是已登录用户才能访问， 还有一些页面可能会要求特定的用户或者用户组的成员才能访问。 这类页面因此也可称为【受限页面】，它们一般代表着比较重要的页面，包含一些重要的操作或功能。
为了保护受限制的页面的访问，ASP.NET提供了一种简单的方式： 可以在web.config中指定受限资源允许哪些用户或者用户组（角色）的访问，也可以设置为禁止访问。
在前面的示例中，有一点要特别注意的是：
1. allow和deny之间的顺序一定不能写错了，UrlAuthorizationModule将按这个顺序依次判断。
2. 如果某个资源只允许某类用户访问，那么最后的一条规则一定是 <deny users="*" />
在allow和deny的配置中，我们可以在一条规则中指定多个用户：
1. 使用users属性，值为逗号分隔的用户名列表。
2. 使用roles属性，值为逗号分隔的角色列表。
3. 问号 (?) 表示匿名用户。
4. 星号 (*) 表示所有用户。
认识Forms身份认证
前面我演示了如何用代码实现登录与注销的过程，下面再来看一下登录时，ASP.NET到底做了些什么事情， 它是如何知道当前请求是一个已登录用户的？
在继续探索这个问题前，我想有必要来了解一下HTTP协议的一些特点。
HTTP是一个无状态的协议，无状态的意思可以理解为：
WEB服务器在处理所有传入请求时，根本就不知道某个请求是否是一个用户的第一次请求与后续请求，或者是另一个用户的请求。
WEB服务器每次在处理请求时，都会按照用户所访问的资源所对应的处理代码，从头到尾执行一遍，然后输出响应内容，
WEB服务器根本不会记住已处理了哪些用户的请求，因此，我们通常说HTTP协议是无状态的。
虽然HTTP协议与WEB服务器是无状态，但我们的业务需求却要求有状态，典型的就是用户登录， 在这种业务需求中，要求WEB服务器端能区分某个请求是不是一个已登录用户发起的，或者当前请求是哪个用户发出的。
在开发WEB应用程序时，我们通常会使用Cookie来保存一些简单的数据供服务端维持必要的状态。
既然这是个通常的做法，那我们现在就来看一下现在页面的Cookie使用情况吧，以下是我用FireFox所看到的Cookie列表：
这个名字：LoginCookieName，是我在web.config中指定的：
<authentication mode="Forms" >
<forms cookieless="UseCookies" name="LoginCookieName" loginUrl="~/Default.aspx"></forms>
</authentication>
在这段配置中，我不仅指定的登录状态的Cookie名，还指定了身份验证模式，以及Cookie的使用方式。
为了判断这个Cookie是否与登录状态有关，我们可以在浏览器提供的界面删除它，然后刷新页面，此时页面的显示效果如下：
为了确认这个Cookie与登录状态有关，我们可以重新登录，然后再退出登录。
发现只要是页面显示当前用户未登录时，这个Cookie就不会存在。
事实上，通过SetAuthCookie这个方法名，我们也可以猜得出这个操作会写一个Cookie。
注意：本文不讨论无Cookie模式的Forms登录。
从前面的截图我们可以看出：虽然当前用户名是 Fish ，但是，Cookie的值是一串乱码样的字符串。
由于安全性的考虑，ASP.NET对Cookie做过加密处理了，这样可以防止恶意用户构造Cookie绕过登录机制来模拟登录用户。
如果想知道这串加密字符串是如何得到的，那么请参考后文。
小结：
1. Forms身份认证是在web.config中指定的，我们还可以设置Forms身份认证的其它配置参数。
2. Forms身份认证的登录状态是通过Cookie来维持的。
3. Forms身份认证的登录Cookie是加密的。
理解Forms身份认证
经过前面的Cookie分析，我们可以发现Cookie的值是一串加密后的字符串， 现在我们就来分析这个加密过程以及Cookie对于身份认证的作用。
登录的操作通常会检查用户提供的用户名和密码，因此登录状态也必须具有足够高的安全性。
在Forms身份认证中，由于登录状态是保存在Cookie中，而Cookie又会保存到客户端，因此，为了保证登录状态不被恶意用户伪造， ASP.NET采用了加密的方式保存登录状态。
为了实现安全性，ASP.NET采用【Forms身份验证凭据】（即FormsAuthenticationTicket对象）来表示一个Forms登录用户， 加密与解密由FormsAuthentication的Encrypt与Decrypt的方法来实现。
用户登录的过程大致是这样的：
1. 检查用户提交的登录名和密码是否正确。
2. 根据登录名创建一个FormsAuthenticationTicket对象。
3. 调用FormsAuthentication.Encrypt()加密。
4. 根据加密结果创建登录Cookie，并写入Response。
在登录验证结束后，一般会产生重定向操作，
那么后面的每次请求将带上前面产生的加密Cookie，供服务器来验证每次请求的登录状态。
每次请求时的（认证）处理过程如下：
1. FormsAuthenticationModule尝试读取登录Cookie。
2. 从Cookie中解析出FormsAuthenticationTicket对象。过期的对象将被忽略。
3. 根据FormsAuthenticationTicket对象构造FormsIdentity对象并设置HttpContext.User
4. UrlAuthorizationModule执行授权检查。
在登录与认证的实现中，FormsAuthenticationTicket和FormsAuthentication是二个核心的类型， 前者可以认为是一个数据结构，后者可认为是处理前者的工具类。
UrlAuthorizationModule是一个授权检查模块，其实它与登录认证的关系较为独立， 因此，如果我们不使用这种基于用户名与用户组的授权检查，也可以禁用这个模块。
由于Cookie本身有过期的特点，然而为了安全，FormsAuthenticationTicket也支持过期策略，
不过，ASP.NET的默认设置支持FormsAuthenticationTicket的可调过期行为，即：slidingExpiration=true 。 这二者任何一个过期时，都将导致登录状态无效。
FormsAuthenticationTicket的可调过期的主要判断逻辑由FormsAuthentication.RenewTicketIfOld方法实现
Request.IsAuthenticated可以告诉我们当前请求是否已经过身份验证， 我们来看一下这个属性是如何实现
从代码可以看出，它的返回结果基本上来源于对Context.User的判断。
另外，由于User和Identity都是二个接口类型的属性，因此，不同的实现方式对返回值也有影响。
由于可能会经常使用HttpContext.User这个实例属性，为了让它能正常使用， DefaultAuthenticationModule会在ASP.NET管线的PostAuthenticateRequest事件中检查此属性是否为null，
如果它为null，DefaultAuthenticationModule会给它一个默认的GenericPrincipal对象，此对象指示一个未登录的用户。
我认为ASP.NET的身份认证的最核心部分其实就是HttpContext.User这个属性所指向的对象。
为了更好了理解Forms身份认证，我认为自己重新实现User这个对象的接口会有较好的帮助。
实现自定义的身份认证标识
前面演示了最简单的ASP.NET Forms身份认证的实现方法，即：直接调用SetAuthCookie方法。 不过调用这个方法，只能传递一个登录名。
但是有时候为了方便后续的请求处理，还需要保存一些与登录名相关的额外信息。
虽然知道ASP.NET使用Cookie来保存登录名状态信息，我们也可以直接将前面所说的额外信息直接保存在Cookie中， 但是考虑安全性，我们还需要设计一些加密方法，而且还需要考虑这些额外信息保存在哪里才能方便使用， 并还要考虑随登录与注销同步修改。
因此，实现这些操作还是有点繁琐的。
为了保存与登录名相关的额外的用户信息，我认为实现自定义的身份认证标识（HttpContext.User实例）是个容易的解决方法。
理解这个方法也会让我们对Forms身份认证有着更清楚地认识。
这个方法的核心是（分为二个子过程）：
1. 在登录时，创建自定义的FormsAuthenticationTicket对象，它包含了用户信息。
2. 加密FormsAuthenticationTicket对象。
3. 创建登录Cookie，它将包含FormsAuthenticationTicket对象加密后的结果。
4. 在管线的早期阶段，读取登录Cookie，如果有，则解密。
5. 从解密后的FormsAuthenticationTicket对象中还原我们保存的用户信息。
6. 设置HttpContext.User为我们自定义的对象。
现在，我们还是来看一下HttpContext.User这个属性的定义：
public IPrincipal User { get; set; }
由于这个属性只是个接口类型，因此，我们也可以自己实现这个接口。
考虑到更好的通用性：不同的项目可能要求接受不同的用户信息类型。所以，我定义了一个泛型类。
这里有必要再补充一下： 登录状态是有过期限制的。
Cookie有 有效期，FormsAuthenticationTicket对象也有 有效期。
这二者任何一个过期时，都将导致登录状态无效。
按照默认设置，FormsAuthenticationModule将采用slidingExpiration=true的策略来处理FormsAuthenticationTicket过期问题。