《基于aspnetForms身份验证基本原理》由会员分享，可在线阅读，更多相关《基于aspnetForms身份验证基本原理（8页珍藏版）》请在金锄头文库上搜索。
1、基于 aspnet Forms身份验证基本原理A的身份验证有有三种，分别是“Windows | Forms | Passport“，其中又以 Forms 验证用的最多，也最灵活。Forms 验证方式对基于用户的验证授权提供了很好的支持，可以通过一个登录页面验证用户的身份，将此用户的身份发回到客户端的Cookie ，之后此用户再访问这个web 应用就会连同这个身份Cookie一起发送到服务端。 服务端上的授权设置就可以根据不同目录对不同用户的访问授权进行控制了。问题来了，在实际是用中我们往往需要的是基于角色，或者说基于用户组的验证和授权。对一个网站来说，一般的验证授权的模式应该是这样的：根据实际
2、需求把用户分成不同的身份，就是角色，或者说是用户组，验证过程不但要验证这个用户本身的身份，还要验证它是属于哪个角色的。而访问授权是根据角色来设置的，某些角色可以访问哪些资源，不可以访问哪些资源等等。要是基于用户来授权访问将会是个很不实际的做法，用户有很多，还可能随时的增减，不可能在配置文件中随时的为不断增加的新用户去增加访问授权的。下面大概的看一下Forms 的过程。Forms 身份验证基本原理：一身份验证要采用 Forms 身份验证，先要在应用程序根目录中的Web.config中做相应的设置 :其中表示本应用程序采用Forms 验证方式。1. 标签中的 name 表示指定要用于身份验证的 H
3、TTP Cookie。默认情况下， name 的值是 .ASPXAUTH。采用此种方式验证用户后, 以此用户的信息建立一个FormsAuthenticationTicket类型的身份验证票 , 再加密序列化为一个字符串 , 最后将这个字符串写到客户端的name 指定名字的 Cookie中. 一旦这个 Cookie写到客户端后 , 此用户再次访问这个web 应用时会将连同Cookie一起发送到服务端 , 服务端将会知道此用户是已经验证过的. 再看一下身份验证票都包含哪些信息呢, 我们看一下 FormsAuthenticationTicket类: CookiePath：返回发出 Cookie 的路
4、径。注意，窗体的路径设置为 / 。由于窗体区分大小写，这是为了防止站点中的 URL 的大小写不一致而采取的一种保护措施。这在刷新 Cookie 时使用Expiration：获取 Cookie 过期的日期 / 时间。IsPersistent ：如果已发出持久的 Cookie，则返回 true。否则，身份验证 Cookie 将限制在浏览器生命周期范围内。IssueDate：获取最初发出 Cookie 的日期 / 时间。Name：获取与身份验证 Cookie 关联的用户名。UserData：获取存储在 Cookie 中的应用程序定义字符串。Version：返回字节版本号供将来使用。2. 标签中的 l
5、oginUrl指定如果没有找到任何有效的身份验证 Cookie，为登录将请求重定向到的 URL。默认值为 default.aspx。loginUrl指定的页面就是用来验证用户身份的, 一般此页面提供用户输入用户名和密码,用户提交后由程序来根据自己的需要来验证用户的合法性( 大多情况是将用户输入信息同数据库中的用户表进行比较),如果验证用户有效 , 则生成同此用户对应的身份验证票, 写到客户端的 Cookie,最后将浏览器重定向到用户初试请求的页面. 一般是用 FormsAuthentication.RedirectFromLoginPage方法来完成生成身份验证票, 写回客户端 , 浏览器重定
6、向等一系列的动作. public static void RedirectFromLoginPage( string userName, boolcreatePersistentCookie, string strCookiePath ); 其中: userName ：就是此用户的标示 , 用来标志此用户的唯一标示, 不一定要映射到用户账户名称. createPersistentCookie：标示是否发出持久的 Cookie。若不是持久 Cookie ，Cookie的有效期 Expiration属性有当前时间加上web.config中 timeout的时间，每次请求页面时，在验证身份过程中，会
7、判断是否过了有效期的一半， 要是的话更新一次cookie的有效期；若是持久 cookie，Expiration属性无意义，这时身份验证票的有效期有cookie的 Expires决定， RedirectFromLoginPage方法给 Expires属性设定的是 50 年有效期。strCookiePath：标示将生成的 Cookie的写到客户端的路径，身份验证票中保存这个路径是在刷新身份验证票Cookie时使用（这也是生成Cookie的 Path ），若没有 strCookiePath参数，则使用 web.config中 path属性的设置。这里可以看到 , 此方法参数只有三个 , 而身份验证票
8、的属性有七个, 不足的四个参数是这么来的: IssueDate： Cookie发出时间由当前时间得出 , Expiration：过期时间由当前时间和下面要说的标签中 timeout参数算出。此参数对非持久性cookie有意义。UserData：这个属性可以用应用程序写入一些用户定义的数据, 此方法没有用到这个属性, 只是简单的将此属性置为空字符串 , 请注意此属性 , 在后面我们将要使用到这个属性。Version：版本号由系统自动提供 . RedirectFromLoginPage方法生成生成身份验证票后，会调用FormsAuthentication.Encrypt方法，将身份验证票加密为字符
9、串， 这个字符串将会是以 .ASPXAUTH 为名字的一个 Cookie的值。 这个 Cookie的其它属性的生成：Domain ，Path属性为确省值， Expires视 createPersistentCookie参数而定，若是持久cookie，Expires设为 50 年以后过期；若是非持久cookie，Expires属性不设置。生成身份验证 Cookie后，将此 Cookie加入到 Response.Cookies中，等待发送到客户端。最后 RedirectFromLoginPage方法调用 FormsAuthentication.GetRedirectUrl方法获取到用户原先请求的页
10、面，重定向到这个页面。3. 标签中的 timeout和 path,是提供了身份验证票写入到Cookie过期时间和默认路径。以上就是基于 Forms 身份验证的过程，它完成了对用户身份的确认。下面介绍基于Forms 身份验证的访问授权。二访问授权验证了身份，是要使用这个身份，根据不同的身份我们可以进行不同的操作，处理，最常见的就是对不同的身份进行不同的授权， Forms 验证就提供这样的功能。 Forms 授权是基于目录的，可以针对某个目录来设置访问权限，比如，这些用户可以访问这个目录，那些用户不能访问这个目录。同样，授权设置是在你要控制的那个目录下的web.config文件中来设置：标签表示允
11、许访问，其中的属性1. users ：一个逗号分隔的用户名列表， 这些用户名已被授予对资源的访问权限。问号 (?) 允许匿名用户； 星号 (*) 允许所有用户。2. roles：一个逗号分隔的角色列表，这些角色已被授予对资源的访问权限。3. verbs ： 一个逗号分隔的 HTTP 传输方法列表，这些 HTTP 传输方法已被授予对资源的访问权限。注册到 ASP.NET 的谓词为 GET、HEAD、POST 和 DEBUG。标签表示不允许访问。其中的属性同上面的。在运行时，授权模块迭代通过和 标记，直到它找到适合特定用户的第一个访问规则。然后，它根据找到的第一项访问规则是 还是 规则来允许或拒绝
12、对 URL 资源的访问。Machine.config文件中的默认身份验证规则是 ，因此除非另行配置，否则在默认情况下会允许访问。那么这些 user 和 roles又是如何得到的呢？下面看一下授权的详细过程：1. 一旦一个用户访问这个网站，就行登录确认了身份，身份验证票的cookie也写到了客户端。之后，这个用户再次申请这个 web 的页面，身份验证票的cookie就会发送到服务端。在服务端，为每一个 http请求都分配一个 HttpApplication对象来处理这个请求，在HttpApplication.AuthenticateRequest事件后，安全模块已建立用户标识， 就是此用户的身份
13、在web 端已经建立起来，这个身份完全是由客户端发送回来的身份验证票的cookie建立的。2. 用户身份在 HttpContext.User属性中，在页面中可以通过Page.Context来获取同这个页面相关的HttpContext对象。对于 Forms 验证，HttpContext.User属性是一个 GenericPrincipal类型的对象，GenericPrincipal只有一个公开的属性Identity，有个私有的 m_role属性，是 string类型，存放此用户是属于哪些 role的数组，还有一个公开的方法IsInRole(string role)，来判断此用户是否属于某个角色。
14、由于身份验证票的cookie中根本没有提供 role这个属性，就是说Forms 身份验证票没有提供此用户的role信息，所以，对于 Forms 验证，在服务端得到的GenericPrincipal用户对象的 m_role属性永远是空的。3. GenericPrincipal. Identity 属性是一个 FormsIdentity类型的对象，这个对象有个Name属性，就是此用户的标示，访问授权就是将此属性做为user来进行授权验证的。 FormsIdentity还有一个属性，就是Ticket属性，此属性是身份验证票FormsAuthenticationTicket类型，就是之前服务器写到客户
15、端的身份验证票。服务器在获取到身份验证票FormsAuthenticationTicket对象后， 查看这个身份验证票是不是非持久的身份验证，是的话要根据 web.config中 timeout属性设置的有效期来更新这个身份验证票的cookie（为避免危及性能，在经过了超过一半的指定时间后更新该 Cookie。这可能导致精确性上的损失。持久性 Cookie 不超时。）4. 在 HttpApplication.ResolveRequestCache事件之前， 开始取得用户请求的页面，建立HttpHandler控制点。这就意味着，在 HttpApplication.ResolveRequestCa
16、che事件要对用户访问权限就行验证，看此用户或角色是否有权限访问这个页面，之后在这个请求的生命周期内再改变此用户的身份或角色就没有意义了。以上是 Forms 验证的全过程，可以看出，这个Forms 验证是基于用户的，没有为角色的验证提供直接支持。身份验证票 FormsAuthenticationTicket中的 Name属性是用户标示，其实还有一个属性UserData，这个属性可以由应用程序来写入自定义的一些数据，我们可以利用这个字段来存放role的信息，从而达到基于角色验证的目的。Forms 身份验证基于角色的授权一身份验证在 web.config的的设置还是一样：/login.aspx验证用户合法性页面中，在验证了用户的合法性后，还要有个取得此用户属于哪些role的过程，这个看各个应用的本身如何设计的了， 一般是在数据库中会有个use_role表， 可以从数据库中获得此用户属于哪些role，在此不深究如何去获取用户对应的role，最后肯定能够获得的此用户对应的所有的role用逗号分割的一个字符串。在上面的非基于角
