关于membership身份验证(飞碟工作室)

一、应用身份验证措施

ASP.NET提供了许多不同类型的身份验证措施供应用程序使用，包括基本身份验证、摘要身份验证、窗体身份验证、Passport身份验证和集成的Windows验证。还可以开发自己的验证方法。如果没有给资源请求应用验证过程，千万不要授予对资源的访问权限。

不同的身份验证模式是通过设置来建立的，而这些设置可以在应用程序的web.config文件中应用，或与应用程序服务器的Internet信息服务(InternetInformationServices，IIS)实例一起使用。

ASP.NET通过应用程序服务器上的一系列.config文件来配置。它们是基于XML的文件，可以很容易地改变ASP.NET的操作方式。这是操作所需配置设置的理想方式。ASP.NET配置文件以层次结构的方式来应用。.NETFramework提供了一个服务器级别的配置文件machine.config，它位于C:/Windows/Microsoft.NET/Framework/v2.0xxxxx/CONFIG。该文件夹包含machine.config和machine.config.comments文件。这些文件提供了服务器级别的ASP.NET应用程序设置，也就是说，这些设置应用于服务器上的每个ASP.NET应用程序。

web.config文件是另一个基于XML的配置文件，它位于Web应用程序的根目录下。web.config文件中的设置会重写上一级machine.config文件中的设置。

甚至还可以嵌套web.config文件，这样，主应用程序的web.config文件位于应用程序的根目录下，而其他web.config文件位于应用程序的子目录下，如图20-1所示。子目录中的web.config文件会重写根目录下的web.config文件。所以，子目录下的web.config文件中的设置会改变应用程序的主web.config文件中的设置。

图1

在本章的许多例子中，都使用web.config文件在应用程序中应用需要的身份验证和授权机制。还可以使用IIS直接把这些设置应用于应用程序。

IIS是处理所有入站HTTP请求的Web服务器。必须修改IIS才能执行希望的操作。只有当页面有特定的文件扩展名(例如.aspx)，IIS才把请求发送给ASP.NET引擎。本章后面将学习如何使用IIS5.0和6.0。

1.1<authentication>节点

在应用程序的web.config文件中使用<authentication>节点，可以设置ASP.NET应用程序需要的身份验证类型：

<system.web>

<authenticationmode="Windows|Forms|Passport|None">

</authentication>

</system.web>

<authentication>节点用mode属性设置要使用的身份验证模式。其选项包括Windows、Forms、Passport和None。表20-1解释了这些选项。

表20-1

提供程序	说明
Windows	Windows身份验证与IIS身份验证一起使用。IIS以如下方式进行验证：basic、digest或IntegratedWindowsAuthentication。IIS验证完成后，ASP.NET就使用已验证的身份授予访问权限。这是默认设置
Forms	未通过验证的请求使用HTTP客户端重定向功能重定向到一个HTML窗体上。用户要提供登录信息，并提交该窗体。如果应用程序验证该请求，系统就发送一个窗体，该窗体包含重新获得身份的凭证或密钥
Passport	这是Microsoft提供的一个集中式身份验证服务，它为成员站点提供了一个登录和核心配置服务。Microsoft从2004年末开始不再强调这种验证模式
None	不使用任何身份验证模式

我们可以使用两种方式为ASP.NET应用程序建立身份验证和授权模型。首先介绍Windows身份验证模式。

二、基于Windows的身份验证

基于Windows的身份验证在ASP.NET应用程序所在的Windows服务器和客户机之间处理。在基于Windows的身份验证模型中，请求直接发送给IIS，进行验证过程。这种类型的身份验证在内联网环境中非常有用。在该环境下，可以让服务器处理这个验证过程，尤其是用户已登录到网络上时，只需获取并利用已有的凭证完成验证过程。

IIS首先从域登录中获得用户的凭证。如果这个过程失败，IIS就显示一个弹出对话框，用户可以在其中输入或重新输入登录信息。要让ASP.NET应用程序使用基于Windows的身份验证，首先要创建一些用户和组。

1.创建用户

使用基于Windows的身份验证可以让已提供域登录的特定用户访问应用程序或其中的一部分。由于使用这种类型的验证模式，所以ASP.NET很容易处理在内联网环境下部署的应用程序。如果用户在本地计算机上登录为一个域用户，在访问该域中的网络计算机时，就不需要再次验证。

下面的步骤说明了如何创建用户。注意，必须有足够的权限才能在服务器上创建用户。如果被授予了该权限，创建用户的步骤就如下所示：

(1) 在VS中建立一个新网站(注意新网站的名称中不要有#或者%之类的符号)，接着点击菜单—>项目—>ASP.NET 配置(T)，注意：在点击此之前，请确认你已经开启了相应的sqlexpress服务哦。

接着进入下面图2的界面。

图 2

(2) 这里要告诉个大家个小技巧的是：最好是先创建角色再创建用户，这样比较方便后面添加用户。点击“启用角色”后，就可以点击“创建或者管理角色”链接后进入下面的界面。

图 3

(3) 这里填上角色后就看下面的图片啦！

图4

(4)接着我们点击选项卡的“安全”返回安全首页，接着点击“创建用户”链接，这里要提醒大家的是用户名的密码至少要满足“字母和特殊符号”一起才能创建成功哦！(记得创建的时候选择右边的用户角色哦)

图5

(5)如果创建好了相应的用户和角色信息,那我们就回到“安全首页”,点击“创建访问规则”链接到下面的界面图6。

图6

(6)这里要提醒的是，要先选择左边网站的目录，如果你想让“Admin ”文件夹下的网页只有特定的用户或者用户组(角色)访问,就先点击下相应的目录，然后在右边选择相应的要求，比如上面的，就说明角色“Admin”具有访问“Admin”文件夹下的所有网页的权限。填写好了点击“确定”就可以了。

（7）接着就可以看到你的响应的规则了图8，这里所示的是Admin文件夹下的访问权限信息。

（8）如果此时你已经开着这个项目并且打开了web.config，当你编辑完了之后再回到VS界面，就会弹出这样的界面(图9)，你只需要点击“全是”就可以了。

图 9

2.用户的身份验证和授权

现在创建一个应用程序，让用户可以进入该应用程序。我们使用应用程序的web.config文件来控制哪些用户允许访问站点，哪些用户不允许访问站点。

把程序清单20-1中的代码添加到web.config文件中。

程序清单20-1通过web.config文件拒绝所有用户

<system.web>

<authentication mode="Forms" />

<authorization>

<denyusers="*"/>

</authorization>

</system.web>

在这个例子中，web.config文件通过<authentication>元素的mode属性，把应用程序配置为使用基于Windows的身份验证。另外，<authorization>元素还用于定义允许访问应用程序的用户或组的特定信息。在本例中，<deny>元素指定拒绝所有用户(即使他们已通过身份验证，也拒绝)访问应用程序。使用<allow>元素可允许特定用户访问，但这个例子只演示<deny>的用法。结果如图20-5所示。

试图访问站点的任何终端用户，无论是已验证的还是未验证的，都会自动跳转到login.aspx这个页面 (图10),如果没有的话就会(如图11)。我们也正是希望所有的用户都不能访问应用程序！

图10

图11

但在大多数情况下，我们都希望允许至少一部分用户访问应用程序。在web.config文件中使用<allow>元素就可以允许某个用户访问。下面是其语法：

<allowusers="Domain/Username"/>

程序清单20-2演示了如何允许用户访问应用程序。

程序清单20-2通过web.config文件允许单个用户访问应用程序

<system.web>

<authenticationmode="Windows"/>

<authorization>

<allowusers="REUTERS-EVJEN/Bubbles"/>

<denyusers="*"/>

</authorization>

</system.web>

即使使用<deny>元素拒绝所有用户(甚至是已验证的用户)访问，<allow>元素中定义的内容也是优先的。在这个例子中，只允许一个用户Bubbles访问应用程序。

现在，如果在客户机上登录为Bubbles用户，在浏览器中运行页面，就可以访问应用程序。

3.<allow>和<deny>节点详解

<allow>和<deny>节点不仅可以操作特定的用户，还可以操作组。这两个元素支持表20-2中的属性。

表20-2

属性	说明
Users	允许通过域和/或名称指定用户
Roles	允许指定允许或拒绝访问的访问组
Verbs	允许指定允许或拒绝访问的HTTP传输方法

在使用这些属性时，可以用星号(*)指定所有的用户：

<allowroles="*"/>

在这个例子中，允许所有的用户访问应用程序。这些属性可以使用的另一个符号是问号(?)，它表示所有的匿名用户。例如，如果阻止所有的匿名用户访问应用程序，可使用下面的代码：

<denyusers="?"/>

在<allow>或<deny>元素中使用users、roles或verbs属性时，可以指定多个项，这些值用逗号隔开。如果允许多个用户访问，可以把这些用户放在不同的元素中，如下所示：

<allowusers="MyDomain/User1"/>

<allowusers="MyDomain/User2"/>

也可以使用下面的代码：

<allowusers="MyDomain/User1,MyDomain/User2"/>

在定义多个角色和动词时，语法与上相同。

4.组的身份验证和授权

可以允许或拒绝组对应用程序或应用程序资源的访问。服务器可以包含许多不同的组(角色)，每个组(角色)都可以有任意多个用户。一个用户还可以属于多个组(角色)。如图12所示。

图12

创建组(角色)后，就可以允许它访问应用程序，如下所示：

<allowroles="Admin"/>

可以使用<allow>或<deny>元素中的roles属性，来操作刚才创建的组(角色)或已有的组(角色)。

5.验证和授权HTTP传输方法

除了身份验证和授权特定的用户或用户组之外，还可以通过特定的HTTP传输协议来接受或拒绝请求。这可以使用allow>或<deny>元素中的verb属性实现：

<denyverbs="GET,DEBUG"/>

在这个例子中，使用HTTPGET或HTTPDEBUG协议传输的请求会被拒绝访问站点。verbs属性的值可以是POST、GET、HEAD和DEBUG。

6.集成的Windows身份验证

前面使用默认的集成Windows身份验证模式进行验证和授权。如果处理的是内联网应用程序，且每个客户机都使用Windows，就没什么问题。Windows是支持该验证模式的唯一系统。这个身份验证系统还要求客户机使用Microsoft的InternetExplorer，但实际情况并非总是如此。

集成的Windows身份验证以前称为NTLM或WindowsNTChallenge/Response身份验证。这个验证模式要求客户机给驻留ASP.NET应用程序的服务器发送其凭证的散列，以此证明其身份。除了Microsoft的ActiveDirectory之外，如果客户机使用的是Microsoft的InternetExplorer5或更高版本，还可以使用Kerberos。

7.基本身份验证

另一个选项是使用基本身份验证，它也要求客户机提供用户名和密码，以验证其身份。基本身份验证的一大优点是，它是HTTP规范的一部分，所以大多数浏览器都支持它。基本身份验证的缺点是，它把用户名和密码作为明文传送给服务器，所以用户名和密码很容易被窃取。因此，基本身份验证必须与SSL(安全套接字层)一起使用。

为了给应用程序应用基本身份验证，必须打开IIS，再打开Web站点的属性对话框。选择”目录安全性”选项卡，单击”目录安全性”框中的“编辑”按钮。打开身份验证方法对话框。

选中下图红线内复选框的选择，如图13所示。此时会显示一个警告，说明这个方法把用户名和密码作为明文传送。

图13

最后单击对话框中的“是”按钮。现在应用程序使用基本身份验证模式，而不是集中式Windows身份验证模式。

8.摘要身份验证

摘要身份验证(digestauthentication)是本次介绍的最后一种模式。该模型解决了基本身份验证把客户机的凭证作为明文传送的问题。摘要身份验证在把客户机的凭证传送给应用程序服务器之前，使用一个算法加密了它们。

要使用摘要身份验证，需要有一个Windows域控制器。摘要身份验证的一个主要问题是，不是所有的平台都支持它，浏览器必须遵循HTTP1.1规范。但摘要身份验证不仅可与防火墙一起工作，还与代理服务器兼容。

在AuthenticationMethods对话框中选中Digestauthentication复选框，就为应用程序选择了摘要身份验证。(不建议使用此种验证)

三、基于窗体的身份验证

基于窗体的身份验证是允许用户访问整个应用程序或其特定资源的一种流行模式。使用它可以把登录窗体直接放在应用程序中，这样，终端用户只需把用户名和密码输入到浏览器中的一个HTML窗体上即可。基于窗体的身份验证的一个缺点是：用户名和密码作为明文传送，除非使用了SSL。

很容易在Web应用程序中实现基于窗体的身份验证。首先修改应用程序的web.config文件，如程序清单3所示。

程序清单3为基于窗体的身份验证修改web.config文件

<system.web>

<authentication mode="Forms">

<forms loginUrl="login.aspx" path="/" cookieless="AutoDetect" protection="Validation" name="formLogin"/>

</authentication>

<authorization>

<deny users="?"/>

</authorization>

</system.web>

这个结构必须应用于web.config文件。首先使用前面介绍的<authorization>元素，可以拒绝所有匿名用户访问应用程序。只有验证用户才能访问应用程序包含的页面。

如果请求者未通过验证，就执行<authentication>元素中定义的内容。mode属性的值设置为Forms，为Web应用程序使用基于窗体的身份验证。下一个指定的属性是loginUrl，它指向包含应用程序的登录窗体的页面。在这个例子中，该页面指定为Login.aspx。如果试图访问应用程序的终端用户未通过身份验证，他的请求就会被重定向到Login.aspx，以便对该用户进行验证和授权。在提供了有效的凭证后，用户就会返回到他在应用程序中最初发出请求的地方。这里使用的最后一个属性是path，它指定了保存cookie的位置。该cookie用于保存授权用户的访问令牌。在大多数情况下，该值默认为/。表3列出了<forms>元素的属性。

表3

属性	说明
name	这是赋予cookie的名称，该cookie用于在请求之间保存用户。其默认值是.ASPXAUTH
loginUrl	如果没有找到有效的验证cookie，就指定将请求重定向到的URL。其默认值是Login.aspx

(续表)

属性	说明
protection	指定要应用于验证cookie的保护级别。它有4个设置： •All:应用程序使用数据有效性验证和加密机制来保护cookie。这是默认设置。 •None:不加密cookie。 •Encryption:加密cookie，但不对它进行数据有效性验证。以这种方式使用的cookie可能会受到纯文本攻击。 •Validation:与Encryption设置相反，进行数据有效性验证，但不加密cookie
path	指定应用程序所用cookie的路径。在大多数情况下应使用/，它是默认设置
timeout	指定cookie过期后的时间(分钟)，其默认值是30
cookieless	指定在进行验证和授权过程中，基于窗体的身份验证过程是否使用cookie
defaultUrl	指定默认的URL
domain	指定要与窗体身份验证cookie一起发送的域名
slidingExpiration	指定是否给cookie应用可变的过期时间。如果该属性设置为True，就对发送给服务器的每个请求重新设置cookie的过期时间。其默认值是False
enableCrossAppsRedirect	指定是否允许跨应用程序的重定向
requireSSL	指定在传输身份验证信息时是否需要SSL连接

有了web.config文件后，就给应用程序创建一个可以访问的页面。

这个页面在浏览器上写入了HelloWorld。窗体身份验证的强大功能在程序清单5的Login.aspx页面中有所体现。

程序清单5Login.aspx页面

C#

<%@PageLanguage="C#"%>

<scriptrunat="server">

protectedvoidButton1_Click(objectsender,EventArgse)

{

if(TextBox1.Text=="BillEvjen"&&TextBox2.Text=="Bubbles"){

FormsAuthentication.RedirectFromLoginPage(TextBox1.Text,true);

}

else{

Response.Write("Invalidcredentials");

}

}

</script>

Login.aspx有两个简单的TextBox控件和一个按钮控件，该按钮控件要求用户提交用户名和密码。Button1_Click事件使用FormsAuthentication类的RedirectFromLoginPage方法。这个方法把请求从Login.aspx重定向到最初请求的资源。

RedirectFromLoginPage方法有两个参数。第一个参数是用户名，用于进行cookie验证。这个参数并不映射为账户名，而是由ASP.NET的URL授权功能使用。第二个参数指定是否生成一个永久的cookie。如果它设置为True，终端用户从一个浏览器会话到下一个会话时，就不需要再次登录。

使用前面构建的3个页面，程序清单20-4中对Default.aspx页面的每个请求都会导致ASP.NET检查是否存在正确的身份验证令牌。如果没有找到该令牌，请求就重定向到指定的登录页面(本例是Login.aspx)。查看浏览器中的URL会发现，ASP.NET使用一个查询字符串值，以确定用户获得授权后把用户返回到什么地方。

http://localhost:1756/login.aspx?ReturnUrl=%2fAdmin%2findex.aspx

其中的查询字符串ReturnUrl使用了最初请求的页面和文件夹的值。

查看程序清单20-5中的Login.aspx页面，注意要检查两个文本框中的值，确保它们遵循特定的用户名和密码。如果用户名和密码正确，就调用RedirectFromLoginPage方法，否则就使用Response.Write语句。在大多数情况下，都不要在代码中对用户名和密码硬编码。还有许多其他选项用于检查用户名和密码是否来自授权用户，下面介绍其中一些选项。

1.根据web.config文件包含的值进行验证

上一个例子不是处理为验证提供的用户名和密码的最佳方式。把这些信息直接硬编码到应用程序并不好。下面把这些值存储在web.config文件中。

在程序清单3中，web.config文件的<forms>元素还可以有子元素。子元素<credentials>允许直接在web.config文件中指定用户名和密码组合。可以用两种方式添加这些值。最简单的方法如程序清单6所示。

程序清单6修改web.config文件，添加用户名和密码值

<system.web>

<authentication mode="Forms">

<forms name="UFO" loginUrl="Login.aspx" path="/">

<credentials passwordFormat="Clear">

<user name="admin" password="admin1~" />

</credentials>

</forms>

</authentication>

<authorization>

<deny users="?" />

</authorization>

</system.web>

<credentials>元素在配置文件中添加了用户及其密码。<credentials>有一个属性passwordFormat，其值可以是Clear、MD5和SHA1。下面描述了这些选项：

●Clear：密码存储为明文。用户的密码直接与这个值比较，不需要进一步转换。

●MD5：密码使用消息摘要5(MessageDigest5，MD5)散列摘要进行存储。在验证凭证时，用户密码使用MD5算法进行散列，再与这个值进行相等比较。不会存储或比较明文密码。这个算法比SHA1的性能好。

●SHA1：密码使用SHA1散列摘要来存储。在验证凭证时，用户密码使用SHA1算法进行散列，再与这个值进行相等比较。不会存储或比较明文密码。这个算法的安全性最高。

在程序清单6的例子中，使用了Clear设置。这不是最安全的方法，但可用于演示。<credentials>的一个子元素是<user>，在该子元素中，可以使用属性name和password为授权用户定义用户名和密码。

接着修改Login.aspx页面上的Button1_Click事件，如程序清单7所示。

程序清单7修改Login.aspx页面以使用web.config文件

C#

<%@PageLanguage="C#"%>

<scriptrunat="server">

protectedvoidButton1_Click(objectsender,EventArgse)

{

if(FormsAuthentication.Authenticate(TextBox1.Text,TextBox2.Text)){

FormsAuthentication.RedirectFromLoginPage(TextBox1.Text,true);

}

else{

Response.Write("Invalidcredentials");

}

}

</script>

在这个例子中，使用Authenticate方法，让ASP.NET页面查找存储在web.config文件中的凭证，以进行验证。Authenticate方法带有两个参数：要检查的用户名和密码。如果找到了凭证，就调用RedirectFromLoginPage方法。

最好不要像上面的例子那样，在web.config文件中把用户的密码存储为明文，而应使用散列功能，防止终端用户的密码被窃取。为此，应在配置文件中保存散列的密码，如程序清单8所示。

程序清单8使用加密的密码

<formsname="UFO"loginUrl="Login.aspx"path="/">

<credentialspasswordFormat="SHA1">

<username="admin"password="58356FB4CAC0B801F011B397F9DFF45ADB863892"/>

</credentials>

</forms>

使用这种构建方式，甚至开发人员都不知道密码，因为没有使用明文密码。Login.aspx页面中的Authenticate方法使用SHA1对密码进行散列(因为这是web.config的<credentials>节点指定的方法)，对这两个散列进行比较。如果它们匹配，就给用户授权。

在使用SHA1或MD5时，唯一要修改的是web.config文件。不必修改登录页面或应用程序的其他页面。但要存储散列的密码，应使用FormsAuthentication.HashPasswordForStoringInConfigFile方法(它是.NETFramework中最长的方法名)，以如下方式进行：

FormsAuthentication.HashPasswordForStoringInConfigFile(TextBox2.Text,"SHA1")

2.根据数据库中的值进行验证

获取用户名和密码的另一个常用方式是直接从数据库中获取。这样可以根据存储在MicrosoftSQLServer中的值检查用户输入的凭证。其代码如程序清单9所示。

程序清单9在SQLServer中检查凭证(Login.aspx)

C#

<%@PageLanguage="C#"%>

<%@ImportNamespace="System.Data"%>

<%@ImportNamespace="System.Data.SqlClient"%>

<scriptrunat="server">

protectedvoidButton1_Click(objectsender,EventArgse)

{

SqlConnectionconn;

SqlCommandcmd;

stringcmdString="SELECT[Password]FROM[AccessTable]WHERE"+

"(([Username]=@Username)AND([Password]=@Password))";

conn=newSqlConnection("DataSource=localhost;Initial"+

"Catalog=usersdb;PersistSecurityInfo=True;UserID=sa");

cmd=newSqlCommand(cmdString,conn);

cmd.Parameters.Add("@Username",SqlDbType.VarChar,50);

cmd.Parameters["@Username"].Value=TextBox1.Text;

cmd.Parameters.Add("@Password",SqlDbType.VarChar,50);

cmd.Parameters["@Password"].Value=TextBox2.Text;

conn.Open();

SqlDataReadermyReader;

myReader=cmd.ExecuteReader(CommandBehavior.CloseConnection);

if(myReader.Read()){

FormsAuthentication.RedirectFromLoginPage(TextBox1.Text,false);

}

else{

Response.Write("Invalidcredentials");

}

myReader.Close();

}

</script>

除了Login.aspx页面之外，其他都与前面的例子相同。现在可以根据存储在SQLServer中的数据验证用户名和密码。在Button1_Click事件中，建立了与SQLServer的连接(为了安全起见，应把连接字符串存储在web.config文件中)。传送参数TextBox1和TextBox2中的输入。如果返回了结果，就调用RedirectFromLoginPage方法。

3.联合使用Login控件和窗体身份验证

前面介绍了如何联合使用ASP.NET窗体身份验证和标准的ASP.NET服务器控件，例如简单的文本框和按钮控件。也可以在定制开发的窗体身份验证架构中使用ASP.NET2.0最新版本的服务器控件，例如新的Login服务器控件。这说明ASP.NET非常强大——可以组合许多不同的部分，构建出希望的解决方案。

程序清单10显示了一个使用新Login服务器控件修改的Login.aspx页面。

程序清单10在Login.aspx页面上使用Login服务器控件

C#

<%@PageLanguage="C#"%>

<scriptrunat="server">

protectedvoidLogin1_Authenticate(objectsender,AuthenticateEventArgse)

{

if(Login1.UserName=="BillEvjen"&&Login1.Password=="Bubbles"){

FormsAuthentication.RedirectFromLoginPage(Login1.UserName,

Login1.RememberMeSet);

}

else{

Response.Write("Invalidcredentials");

}

}

</script>

页面上没有Button服务器控件，所以使用Login控件的OnAuthenticate属性指向身份验证服务器端事件Login1_Authenticate。该事件查找授权信息(但本例中将其值硬编码了)。Login控件的用户名文本框可以通过Login1.UserName声明访问，密码可以使用Login1.Password访问。Login1.RememberMeSet属性用于指定是否存储用户的验证cookie，这样在下次访问时用户就不必验证身份了。

这个例子比使用文本框和按钮控件创建自己的登录窗体简单得多。可以给Login控件提供预定义的外观和操作方式，也可以使用Login控件的子控件属性。总之，在ASP.NET应用程序中使用什么方法取决于我们自己。

4.FormsAuthentication类

从本章的窗体身份验证一节的各例子可以看出，许多任务的实现都取决于FormsAuthentication类。所以，下面看看这个类。

FormsAuthentication类有许多方法和属性，可以读取和控制验证cookie以及其他信息(例如请求的返回URL)。表4列出了FormsAuthentication类的一些方法和属性。

表4

方法/属性	说明
Authenticate	这个方法用于验证存储在配置文件(例如web.config)中的凭证
Decrypt	返回一个有效的加密验证票据实例，该实例从HTTPcookie中提取，是FormsAuthenticationTicket类的一个实例
Encrypt	创建一个字符串，其中包含一个有效的加密验证票据实例，该实例可用于HTTPcookie
FormsCookieName	给当前应用程序返回cookie的名称
FormsCookiePath	给当前应用程序返回cookie的路径(cookie的位置)
GetAuthCookie	给指定的用户提供一个验证cookie
GetRedirectUrl	返回一个URL，用户通过登录页面授权后，就会重定向到这个URL上
HashPasswordFor Storing InConfigFile	创建所提供的字符串密码的散列。这个方法带两个参数，一个是密码，另一个是要在字符串上实现的散列类型。散列值可以是SHA1和MD5
Initialize	通过从web.config文件中读取配置设置，以及获取应用程序的给定实例中使用的cookie和加密键，来执行FormsAuthentication类的初始化
RedirectFromLogin Page	把HTTP请求重定向回最初请求的页面。只能在用户获得授权后执行这个操作
RenewTicketIfOld	在FormsAuthenticationTicket实例上有条件地更新可变的过期时间
RequireSSL	指定cookie是否应只通过SSL(HTTPS)传输
SetAuthCookie	创建一个验证票据，把它关联到输出响应包含的cookie
SignOut	删除验证票据
SlidingExpiration	提供一个布尔值，表示过期时间是否可变

20.2.4Passport身份验证

验证终端用户的另一种方法是使用Microsoft的Passport标识系统。有Passport账户的用户可以有一个签名解决方案，也就是说，他只需这些凭证就可以登录到Internet的站点和其他支持Passport的站点和应用程序上。

应用程序支持Passport身份验证时，请求会被重定向到MicrosoftPassport站点上，在该站点上，用户可以输入凭证。如果验证成功，用户就可以获得授权，请求被重定向回应用程序。

很少有Internet站点和应用程序使用Microsoft的Passport技术。实际上，Microsoft在2005年完全抛弃了Passport，大多数对全局身份验证和授权标准感兴趣的公司都转而使用ProjectLiberty作为其解决方案(www.projectliberty.org)。