ASP.NET中的身份验证及授权

用ASP.NET建立的每个页面并不对Internet上的每个人都开放。有时，应用程序中的页面或部分只能由一组拥有访问权限的用户访问。所以，需要采取本章介绍的安全措施，它们可以保护应用程序中的数据，防止应用程序被误用。
安全性是一个含义非常广泛的术语。毫无疑问，在建立应用程序的每一步中，都必须仔细考虑怀有恶意的终端用户可能试图绕过安全措施的方式。必须采取措施确保没有人能接管应用程序或者访问其资源。无论是涉及到基本服务器控件，还是数据库的访问，都应考虑采取安全措施保护。
安全措施如何应用到应用程序上是一个有一定规律的过程。例如，Internet上一个对公众开放的ASP.NET页面与只能由选定的人使用的ASP.NET应用程序有不同的安全要求，因为该ASP.NET页面要处理诸如信用卡号码或医药等机密信息。
第一步是给手边的任务应用相应的安全措施。我们可以采取许多不同的措施来保护应用程序和资源，所以必须决定采用哪些措施。本章将介绍保护应用程序的一些措施。
注意，安全性将贯穿全书来讨论。另外，还有两章讨论本章未探讨的ASP.NET 2.0提供的新安全性架构。第17和18章讨论了ASP.NET新增的成员和角色管理架构，以及这个版本中的新个性化特性。这些主题都是安全性的内容，大大简化了安全应用程序的建立。这些新的安全性架构是ASP.NET最新版本提供的，但我们仍可以像在ASP.NET的以前版本中那样建立自己的安全措施，本章就讨论这些内容。
安全性的一个重要方面是如何处理身份验证和对应用程序中资源的访问授权。在开始使用ASP.NET中的身份验证和授权功能之前，应先了解这两个术语的含义。

20.1 身份验证和授权

如第18章所述，身份验证是确定用户身份的过程。在用户通过了身份验证后，开发人员就可以确定该用户是否有权继续操作。如果没有进行身份验证，就不能进行实体的授权。
授权是确定已验证的用户是否有权访问应用程序中的某个部分、某个点、或只访问应用程序提供的特定数据集。对用户和组进行身份验证和授权后，就可以根据用户类型或配置定制站点。

20.2 应用身份验证措施

ASP.NET提供了许多不同类型的身份验证措施供应用程序使用，包括基本身份验证、摘要身份验证、窗体身份验证、Passport身份验证和集成的Windows验证。还可以开发自己的验证方法。如果没有给资源请求应用验证过程，千万不要授予对资源的访问权限。
不同的身份验证模式是通过设置来建立的，而这些设置可以在应用程序的web.config文件中应用，或与应用程序服务器的Internet信息服务(Internet Information Services，IIS)实例一起使用。
ASP.NET通过应用程序服务器上的一系列.config文件来配置。它们是基于XML的文件，可以很容易地改变ASP.NET的操作方式。这是操作所需配置设置的理想方式。ASP.NET配置文件以层次结构的方式来应用。.NET Framework提供了一个服务器级别的配置文件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文件中的设置。



图 20-1
在本章的许多例子中，都使用web.config文件在应用程序中应用需要的身份验证和授权机制。还可以使用IIS直接把这些设置应用于应用程序。
IIS是处理所有入站HTTP请求的Web服务器。必须修改IIS才能执行希望的操作。只有当页面有特定的文件扩展名(例如.aspx)，IIS才把请求发送给ASP.NET引擎。本章后面将学习如何使用IIS 5.0 和6.0。

20.2.1 <authentication>节点

在应用程序的web.config文件中使用<authentication>节点，可以设置ASP.NET应用程序需要的身份验证类型：
<system.web>
<authentication mode="Windows|Forms|Passport|None">
</authentication>
</system.web>
<authentication>节点用mode属性设置要使用的身份验证模式。其选项包括Windows、Forms、Passport和None。表20-1解释了这些选项。
表 20-1

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

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

20.2.2 基于Windows的身份验证

基于Windows的身份验证在ASP.NET应用程序所在的Windows服务器和客户机之间处理。在基于Windows的身份验证模型中，请求直接发送给IIS，进行验证过程。这种类型的身份验证在内联网环境中非常有用。在该环境下，可以让服务器处理这个验证过程，尤其是用户已登录到网络上时，只需获取并利用已有的凭证完成验证过程。
IIS首先从域登录中获得用户的凭证。如果这个过程失败，IIS就显示一个弹出对话框，用户可以在其中输入或重新输入登录信息。要让ASP.NET应用程序使用基于Windows的身份验证，首先要创建一些用户和组。

1. 创建用户

使用基于Windows的身份验证可以让已提供域登录的特定用户访问应用程序或其中的一部分。由于使用这种类型的验证模式，所以ASP.NET很容易处理在内联网环境下部署的应用程序。如果用户在本地计算机上登录为一个域用户，在访问该域中的网络计算机时，就不需要再次验证。
下面的步骤说明了如何创建用户。注意，必须有足够的权限才能在服务器上创建用户。如果被授予了该权限，创建用户的步骤就如下所示：
(1) 在Windows XP或Windows Server 2003服务器上，选择Start | Control Panel | Administrative Tools | Computer Management，打开Computer Management实用程序。它管理和控制本地Web服务器上的资源。可以使用这个实用程序完成许多任务。但这里主要考虑用户的创建。
(2) 展开System Tools节点。
(3) 展开Local Users and Groups节点。
(4) 选择Users文件夹，结果如图20-2所示。



图 20-2
(5) 右击Users文件夹，选择New User，打开New User对话框，如图20-3所示。



图 20-3
(6) 给用户指定名称、密码和描述(说明这是一个测试用户)。这个例子把用户命名为Bubbles。
(7) 取消需要用户在下次登录时修改密码的复选框的选中状态。
(8) 单击Create按钮，就创建了测试用户，它会显示在Computer Management实用程序的Users文件夹中，如图20-4所示。



图 20-4
下面创建一个页面，来使用这个用户。

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

现在创建一个应用程序，让用户可以进入该应用程序。我们使用应用程序的web.config文件来控制哪些用户允许访问站点，哪些用户不允许访问站点。
把程序清单20-1中的代码添加到web.config文件中。
程序清单20-1 通过web.config文件拒绝所有用户
<system.web>
<authentication mode="Windows" />
<authorization>
<deny users="*" />
</authorization>
</system.web>
在这个例子中，web.config文件通过<authentication>元素的mode属性，把应用程序配置为使用基于Windows的身份验证。另外，<authorization>元素还用于定义允许访问应用程序的用户或组的特定信息。在本例中，<deny>元素指定拒绝所有用户(即使他们已通过身份验证，也拒绝)访问应用程序。使用<allow>元素可允许特定用户访问，但这个例子只演示<deny>的用法。结果如图20-5所示。
试图访问站点的任何终端用户，无论是已验证的还是未验证的，都会在浏览器窗口中看到Access is denied语句。我们正是希望所有的用户都不能访问应用程序！



图 20-5
但在大多数情况下，我们都希望允许至少一部分用户访问应用程序。在web.config文件中使用<allow>元素就可以允许某个用户访问。下面是其语法：
<allow users="Domain/Username" />
程序清单20-2演示了如何允许用户访问应用程序。
程序清单20-2 通过web.config文件允许单个用户访问应用程序
<system.web>
<authentication mode="Windows" />
<authorization>
<allow users="REUTERS-EVJEN/Bubbles" />
<deny users="*" />
</authorization>
</system.web>
即使使用<deny>元素拒绝所有用户(甚至是已验证的用户)访问，<allow>元素中定义的内容也是优先的。在这个例子中，只允许一个用户Bubbles访问应用程序。
现在，如果在客户机上登录为Bubbles用户，在浏览器中运行页面，就可以访问应用程序。

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

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

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

在使用这些属性时，可以用星号(*)指定所有的用户：
<allow roles="*" />
在这个例子中，允许所有的用户访问应用程序。这些属性可以使用的另一个符号是问号(?)，它表示所有的匿名用户。例如，如果阻止所有的匿名用户访问应用程序，可使用下面的代码：
<deny users="?" />
在<allow>或<deny>元素中使用users、roles或verbs属性时，可以指定多个项，这些值用逗号隔开。如果允许多个用户访问，可以把这些用户放在不同的元素中，如下所示：
<allow users="MyDomain/User1" />
<allow users="MyDomain/User2" />
也可以使用下面的代码：
<allow users="MyDomain/User1, MyDomain/User2" />
在定义多个角色和动词时，语法与上相同。

4. 组的身份验证和授权

可以允许或拒绝组对应用程序或应用程序资源的访问。服务器可以包含许多不同的组，每个组都可以有任意多个用户。一个用户还可以属于多个组。打开Computer Management实用程序(Start | Control Panel | Administrative Tools | Computer Management)，访问在服务器上定义的组列表。单击Computer Management实用程序中的Groups文件夹，就会显示组的列表，如图20-6所示。



图 20-6
右击Groups文件夹，选择New Group，打开New Group对话框，如图20-7所示。



图 20-7
要创建一个组，应指定它的名称和描述；然后单击Add按钮，选择要成为该组中成员的用户。创建组后，就可以允许它访问应用程序，如下所示：
<allow roles="MyGroup" />
可以使用<allow>或<deny>元素中的roles属性，来操作刚才创建的组或已有的组。

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

除了身份验证和授权特定的用户或用户组之外，还可以通过特定的HTTP传输协议来接受或拒绝请求。这可以使用allow>或<deny>元素中的verb属性实现：
<deny verbs="GET, DEBUG" />
在这个例子中，使用HTTP GET或HTTP DEBUG协议传输的请求会被拒绝访问站点。verbs属性的值可以是POST、GET、HEAD和DEBUG。

6. 集成的Windows身份验证

前面使用默认的集成Windows身份验证模式进行验证和授权。如果处理的是内联网应用程序，且每个客户机都使用Windows，就没什么问题。Windows是支持该验证模式的唯一系统。这个身份验证系统还要求客户机使用Microsoft的Internet Explorer，但实际情况并非总是如此。
集成的Windows身份验证以前称为NTLM或Windows NT Challenge/Response身份验证。这个验证模式要求客户机给驻留ASP.NET应用程序的服务器发送其凭证的散列，以此证明其身份。除了Microsoft的Active Directory之外，如果客户机使用的是Microsoft的Internet Explorer 5或更高版本，还可以使用Kerberos。

7. 基本身份验证

另一个选项是使用基本身份验证，它也要求客户机提供用户名和密码，以验证其身份。基本身份验证的一大优点是，它是HTTP规范的一部分，所以大多数浏览器都支持它。基本身份验证的缺点是，它把用户名和密码作为明文传送给服务器，所以用户名和密码很容易被窃取。因此，基本身份验证必须与SSL(安全套接字层)一起使用。
为了给应用程序应用基本身份验证，必须打开IIS，再打开Web站点的Properties对话框。选择Directory Security选项卡，单击Anonymous Access and Authentication Control框中的Edit按钮。打开Authentication Methods对话框。
取消对底部Integrated Windows authentication复选框的选择，再选中它上面的Basic authentication复选框，如图20-8所示。此时会显示一个警告，说明这个方法把用户名和密码作为明文传送。



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

8. 摘要身份验证

摘要身份验证(digest authentication)是本节介绍的最后一种模式。该模型解决了基本身份验证把客户机的凭证作为明文传送的问题。摘要身份验证在把客户机的凭证传送给应用程序服务器之前，使用一个算法加密了它们。
要使用摘要身份验证，需要有一个Windows域控制器。摘要身份验证的一个主要问题是，不是所有的平台都支持它，浏览器必须遵循HTTP 1.1规范。但摘要身份验证不仅可与防火墙一起工作，还与代理服务器兼容。
在Authentication Methods对话框中选中Digest authentication复选框，就为应用程序选择了摘要身份验证