.net 身份验证方式有哪些及原理

       Asp.net的身份验证有有三种，分别是"Windows | Forms | Passport"，其中又以Forms验证用的最多，也最灵活。

      Windows: 使用IIS验证方式

      Forms: 使用基于窗体的验证方式
      Passport: 采用Passport cookie验证模式

      None: 不采用任何验证方式

1、Forms
      Forms 验证方式对基于用户的验证授权提供了很好的支持，可以通过一个登录页面验证用户的身份，将此用户的身份发回到客户端的Cookie，之后此用户再访问这个 web应用就会连同这个身份Cookie一起发送到服务端。服务端上的授权设置就可以根据不同目录对不同用户的访问授权进行控制了。

问题来了，在实际应用中我们往往需要的是基于角色，或者说基于用户组的验证和授权。对一个网站来说，一般的验证授权的模式应该是这样的：根据实际需 求把用户分成不同的身份，就是角色，或者说是用户组，验证过程不但要验证这个用户本身的身份，还要验证它是属于哪个角色的。而访问授权是根据角色来设置 的，某些角色可以访问哪些资源，不可以访问哪些资源等等。要是基于用户来授权访问将会是个很不实际的做法，用户有很多，还可能随时的增减，不可能在配置文 件中随时的为不断增加的新用户去增加访问授权的。

下面大概的看一下Forms的过程。

        Forms身份验证基本原理：

要采用Forms身份验证，先要在应用程序根目录中的Web.config中做相应的设置:
<authentication mode="forms"> <forms name=".ASPXAUTH " slidingExpiration="true" loginUrl="/login.aspx" timeout="30" path= "/" domain=".abc.com"> </forms> </authentication>
通过 <authentication> 节可以配置 ASP.NET 用来识别进入用户的安全身份验证模式。
其中<authentication mode= "forms"> 表示本应用程序采用Forms验证方式。
<forms>标签中的name表示指定要用于身份验证的 HTTP Cookie。默认情况下，name 的值是 .ASPXAUTH。采用此种方式验证用户后,以此用户的信息建立一个FormsAuthenticationTicket类型的身份验证票,再加密序列 化为一个字符串,最后将这个字符串写到客户端的name指定名字的Cookie中.一旦这个Cookie写到客户端后,此用户再次访问这个web应用时会 将连同Cookie一起发送到服务端,服务端将会知道此用户是已经验证过的.
再看一下身份验证票都包含哪些信息呢,我们看一下FormsAuthenticationTicket类:
CookiePath： 返回发出 Cookie 的路径。注意，窗体的路径设置为 /。由于窗体区分大小写，这是为了防止站点中的 URL 的大小写不一致而采取的一种保护措施。这在刷新 Cookie 时使用 Expiration： 获取 Cookie 过期的日期/时间。 IsPersistent： 如果已发出持久的 Cookie，则返回 true。否则，身份验证 Cookie 将限制在浏览器生命周期范围内。 IssueDate： 获取最初发出 Cookie 的日期/时间。 Name： 获取与身份验证 Cookie 关联的用户名。 UserData ：获取存储在 Cookie 中的应用程序定义字符串。 Version： 返回字节版本号供将来使用。

2、Windows

        提供有关如何将 Windows 身份验证与 Microsoft Internet 信息服务 (IIS) 身份验证结合使用来确保 ASP.NET 应用程序安全的信息。

3、Passport

      Passport 身份验证是由 Microsoft 提供的集中身份验证服务，该服务为成员站点提供单一登录和核心配置文件服务。由于访问新的受保护资源或站点时不再需要登录，所以它有益于用户。如果希望您的站点与 Passport 身份验证及授权兼容，则应该使用该提供程序。本主题提供一些有关 Microsoft .NET Passport 及其 ASP.NET 支持的介绍性材料。有关更多信息，请参见位于 http://www.pplsunny.com/business 的 Passport 文档。要访问该文档，必须获取 Passport 并注册。

        Passport 是基于 Cookie 的身份验证服务。使用 Passport 身份验证的示例事务对话可能类似于下面的内容：
客户对受保护资源（如 http://www.pplsunny.com/default.aspx）发出 HTTP GET 请求。
检查客户的 Cookie 是否具有现有的 Passport 身份验证票。如果站点找到有效的凭据，则站点对该客户进行身份验证。如果请求不包括有效的身份验证票，则服务器返回状态代码 302 并将客户重定向到 Passport 登录服务。响应在查询字符串中包含一个 URL，该 URL 被发送到 Passport 登录服务以便将客户定向回原始站点。
客户遵循重定向，向 Passport 登录服务器发出一个 HTTP GET 请求，并传输来自原始站点的查询字符串信息。
        Passport 登录服务器向客户提供登录窗体。
客户填写窗体并使用安全套接字层 (SSL) 通过 POST 发送回登录服务器。
登录服务器对用户进行身份验证并将客户重定向回原始 URL (http://www.pplsunny.com/default.aspx)。响应在查询字符串中包含一个加密的 Passport Cookie。
       客户遵循重定向并再次请求原始的受保护资源，这一次使用 Passport Cookie。
在起始服务器上，PassportAuthenticationModule 检测是否存在 Passport Cookie 并测试身份验证。如果成功，则该请求通过身份验证。