ASP.NET中实现身份验证方案

一、.NET中实现身份验证的可行性

 

Internet Information Services(IIS)   和  ASP .NET  均提供了安全模型，以便您对用户进行适当的身份验证。  

ASP.NET 与 IIS 一起使用以支持身份验证，并使用基本、简要和 Windows 身份验证。 ASP.NET 支持 Microsoft Passport 身份验证服务，该服务提供单一登录服务和对用户配置文件服务的支持。 ASP.NET 还为要使用基于窗体的身份验证的应用程序提供可靠的服务。基于窗体的身份验证使用 Cookie 鉴别用户的身份，并允许应用程序执行自己的凭据验证。

 

二、.NET中选择身份验证方法的考虑因素

(1) 、服务器和客户端操作系统；

(2) 、客户端浏览器类型；

(3) 、用户数量、位置、用户名以及密码数据库类型；

(4) 、部署考虑，如应用程序是基于 Internet 还是 Intranet，及其是否

位于防火墙之后；

(5) 、应用程序类型，如，是交互式网站还是非交互式 Web 服务；

(6) 、要保护的数据的敏感度；

(7) 、性能和可伸缩性因素；

(8) 、身份验证要求。例如，您希望所有用户均可使用应用程序；或希望

限制某些区域仅供注册用户使用，而另一些区域“仅限管理员使用” 。

 

三、.NET中实现身份验证的各种方法比较

3.1 匿名身份验证

使用匿名身份验证，服务器不请求客户端向其发送用户凭据。如果您的站点或服务可供公开使用，而您不必知道呼叫方的标识，那么这就是一个好的选择。同时，也不会由于与支持的身份验证机制不兼容而造成浏览器限制。所有用户均可访问配置为匿名身份验证的站点。

** 典型应用方案：

以下情况下，您应考虑使用匿名身份验证： 

(1) 无论是对于登录还是业务逻辑组件，您都不需要知道呼叫方的名字和/或密码。

(2) 您所保护的信息被认为是“公有的”。 

以下情况下，您不应考虑使用匿名身份验证： 

您要求使用登录名和密码以限制用户群。 

** 实现

要实现匿名身份验证，应为匿名身份验证配置  IIS  并配置适当的匿名用

户帐户。使用  Web.config  文件配置  ASP .NET  以使用无身份验证 。  

 

3.2 基本身份验证

当  IIS  配置为基本身份验证时，它将指示浏览器通过  HTTP  发送用户凭据。密码和用户名使用  Base64  编码方法进行编码。尽管密码已经编码，但由于其解密相对较容易，所以仍然是不安全的。浏览器将通过对话框提示用户，然后重新发出原始匿名请求和提供的凭据（包括用户名和密码）。弹出式登录对话框不一定适合您的用户界面设计要求。大多数  Internet  浏览器支持基本身份验证。  

** 典型应用方案

    以下情况下，您应考虑使用基本身份验证：  

(1) 您的用户具有  Windows NT  域或  Active Directory  帐户。  

(2) 您需要支持多个浏览器类型，包括  Netscape Navigator  和所有版本的  Internet Explorer （包括  Pocket PC  和  Windows CE  平台）。  

(2) 您需要支持通过  Internet  进行身份验证。  

(3) 您需要在应用程序代码中访问明文密码。  

(4) 您需要支持代理。  

    以下情况下，您不应考虑使用基本身份验证：  

(1) 需要安全登录且不使用安全通道，例如由安全套接字层  (SSL)  提供的通道。

(2) 您的用户存储在自定义数据库中，并且没有  Windows  帐户。  

(3) 您需要一个自定义表单作为登录页提供给用户。  

 ** 实现

要实现基本身份验证，应在  IIS  内对其进行配置，并确保您的用户在  Web  服务器上具有 “ 本地登录 ” 权限。如果您的  ASP .NET  应用程序需要作为经过基本身份验证的用户来运行，   需要对 Web.config  文件进行相应的配置。  

 

3.3 简要身份验证

简要身份验证是  Windows 2000  和  IIS 5.0  的新功能。这种身份验证形式能够加密用户的密码信息并提供一种机制以便防止某些常见的服务器攻击（如重放攻击）。简要身份验证不像基本身份验证那样使用明文通过网络发送凭据。相反，它使用一种由  RSA  开发的散列机制，称为  MD5 。尽管它对于  Internet  来说是一个可行的身份验证选择，但客户端和服务器的要求限制了它的广泛使用。 IIS  与基本身份验证不同，而与  NTLM  和  Kerberos  类似。它不在本地登录  Web  服务器，因此不能执行代理。  

** 典型应用方案

    以下情况下，您应考虑使用简要身份验证：  

(1) 您的  Web  服务器运行  Windows 2000 ，并且您的用户在  Active Directory  中存储有  Windows  帐户。  

(2) 您所有的客户端均使用  .NET  平台或  Internet Explorer 5.x 。  

(3) 您需要比基本身份验证更强大的密码加密方法。  

(4) 您需要支持通过  Internet  进行身份验证。  

    以下情况下，您不应考虑使用简要身份验证：  

(1) 您的某些客户端使用非  .NET  或  Internet Explorer 5.0 （或更高版本）的平台。  

(2) 您的用户在  Active Directory  中没有存储  Windows  帐户。  

(3) 您需要代理。

** 实现

您必须为简要身份验证配置  IIS 。如果您的  ASP .NET  应用程序需要作为已进行  IIS  简要身份验证的验证用户来运行，可以对  Web.config 进行相应   配置。

 

3.4 集成 Windows 身份验证

集成  Windows  身份验证（使用  NTLM  挑战 / 响应或  Kerberos ）涉及对具有  Windows NT  域或  Active Directory  帐户的用户进行身份验证。与基本身份验证和简要身份验证不同，在该方法中加密密码不通过网络发送，因而非常安全。如果服务器中安装有  Active Directory  服务，且浏览器与  Kerberos V5  身份验证协议兼容，则将使用  Kerberos V5  协议和挑战 / 响应协议，否则将仅使用挑战 / 响应协议。该方法最适合  Intranet  环境。在这种环境中，用户和  Web  服务器计算机在同一个域中，管理员可以保证每台计算机均运行  Microsoft Internet Explorer  版本  3.01  或更高版本。  

** 典型应用方案

    以下情况下，您应考虑使用集成  Windows  身份验证：  

(1) 您的用户具有  Windows NT  域或  Active Directory  帐户。  

(2) 您的应用程序运行于  Intranet  上（在防火墙后）。  

(3) 所有客户端均运行  Internet Explorer  版本  3.01  或更高版本。  

(4) 您需要执行代理（这需要  Kerberos ）。  

(5) 您需要为域用户采用无缝登录程序（例如，没有弹出式登录对话框）。  

    以下情况下，您不应考虑使用集成  Windows  身份验证：  

(1) 您的用户帐户是存储在外部数据库中，而不是存储在  Windows NT  域数据库或  Active Directory  中。  

(2) 您需要支持通过  Internet  进行身份验证。  

(3) 您的客户端使用  Netscape Navigator  或其他非  Microsoft  浏览器。  

(4) 您需要获得客户的明文密码。  

** 实现

    要实现  Kerberos  或  NTLM ，您需要配置  IIS  以使用集成  Windows  身份验证。如果您需要支持运行非  Internet Explorer  的客户端，则可以启用基本身份验证以结合  NTLM  或  Kerberos 。  

    配置  Kerberos  时，您需要考虑这些特定细节：  

(1) 客户端和服务器必须都在同一  Windows 2000  域中运行  Windows 2000 。  

(2) 必须启用客户端的用户帐户以使用代理。  

(3) 必须启用服务器的帐户以使用代理。

    如果您的  ASP .NET  应用程序需要作为已由  IIS  使用集成  Windows  身份验证进行过验证的用户来运行，可以对  Web.config 文件进行相应的   配置。

 

3.5 证书身份验证

证书是安装在计算机中的数字 “ 密钥 ” 。计算机试图访问服务器时，密钥将自动传送以对用户进行身份验证。客户端证书可被映射到域或  Active Directory  中的  Windows  帐户。如果您在  ASP .NET  中使用  Windows  身份验证提供程序，应用程序线程将作为证书所映射的用户运行。您也可在  ASP .NET  中实现自定义身份验证，例如，您可以使用证书内包含的电子邮件地址（或类似的唯一字段）。从客户端的观点来看，安全性是无缝的，因为客户端不需要使用登录页来登录。这就使得证书在自动化业务流程方面成为一个有吸引力的选择。  

** 典型应用方案

    以下情况下，您应考虑使用证书身份验证：  

(1) 您所保护的数据非常敏感，您需要非常安全的解决方案。  

(2) 您需要互相身份验证。  

(3) 您希望第三方能够管理服务器和证书拥有者之间的关系。  

(4) 您希望实现无缝的客户端交互，例如自动  B2B  交易。

    以下情况下，您不应考虑使用证书身份验证：  

发布和管理客户端证书的成本超过了增加安全性所获得的价值。  

** 实现

    您必须配置  IIS  以进行证书身份验证。

 

3.6 Passport 身份验证

Passport  身份验证是由  Microsoft  提供的集中身份验证服务。使用  Passport  时，在某些情况下您不必实现自己的身份验证代码、登录页和用户表。 Passport  使用  Cookie  机制工作。如果客户端以前已经通过了  Passport  验证，则允许它们访问您的站点。否则，它们将被自动重定向到  Passport  站点以进行身份验证。  

    如果您需要在多个域之间进行单一登录（这些域也支持  Passport ），那么  Passport  是一个好选择。 Passport  不仅提供身份验证服务，还提供包括配置文件管理和采购服务在内的其他服务。  

    在  Windows 2000  平台上， Passport  没有直接集成到操作系统内部的任何身份验证和授权机制。 .NET  框架确实会检查  Passport Cookie ，但如果您维护自己的数据库，您必须实现自己的代码，以将  Passport  用户映射为自己的用户，同时还要实现自己的授权机制。  

** 典型应用方案

    以下情况下，您应考虑使用  Passport  身份验证：  

(1) 您的站点要与其他启用  Passport  的站点结合使用，同时您希望访问这些站点的用户能够进行单一登录。  

(2) 您不想维护用户名和密码数据库。

    以下情况下，您不应考虑使用  Passport  身份验证：  

(1) 您希望使用已经存储在自己的数据库或  Active Directory  中的用户名和密码。（尽管有可能使用额外的代码将  Passport ID  映射为用户帐户。）  

(2) 您的客户端是通过编程来访问站点的其他计算机。  

 ** 实现

    要实现  Passport ，您需要在服务器中安装  Passport SDK 。您还需要向  Passport  注册以使用服务。您必须配置  web.config  文件。  

 

3.7 表单身份验证

表单身份验证是指接受用户凭据的自定义用户界面组件，例如，一个用户名和密码。现在使用的许多  Internet  应用程序具有这种供用户登录的表单。值得注意的是，表单本身并不执行身份验证，它仅仅是一种获得用户凭据的方法。身份验证是通过使用自定义代码访问用户名和密码数据库来实现的。  

验证用户身份后，服务器一般会通过某种方式向客户端表明其已经通过身份验证，可以进行后续请求。如果需要，您可以强制用户验证每个请求，但这样会影响性能和可伸缩性。您应考虑两种基本方法来识别以前登录过的客户端：  

    (1)Cookie 。 Cookie  是最初由服务器向客户端发送的一小段数据。随后，由客户端随每个  HTTP  请求将其发送回服务器。它可以用作客户端已经通过身份验证的标志。 ASP .NET  通过  CookieAuthenticationProvider  模块为您提供了使用  Cookie  进行表单身份验证的机制。大多数  Web  浏览器（包括  Internet Explorer  和  Netscape Navigator ）均支持  Cookie 。  

    (2) 自定义。您可以实现自己的自定义机制来向服务器标识客户端。如果您的客户端禁用了  Cookie ，您可以考虑在每个  URL  查询字符串中存储一个唯一标识符。或者使用存储在永久性顶级或不可见框架中的隐藏表单域。无论如何，您要确保黑客不能通过编程模拟成已经通过应用程序身份验证的用户。  

    Cookie  广泛应用于使用表单身份验证的网站。 .NET  的最初版本将仅支持使用  Cookie  的表单身份验证。  

** 典型应用方案

    以下情况下，您应考虑使用表单验证：  

(1) 用户名和密码存储在  Windows  帐户以外的位置。请注意， Windows  帐户也可以使用表单身份验证。  

(2) 您要在  Internet  上部署应用程序。  

(3) 您需要支持所有浏览器和客户端操作系统。  

(4) 您希望为用户提供自己的用户界面表单作为登录页。  

    以下情况下，您不应考虑使用表单验证：  

(1) 您要为公司  Intranet  部署应用程序，并且可以利用集成  Windows  身份验证。  

(2) 您不能通过编程访问来验证用户名和密码。

** 实现

    要实现表单身份验证，您必须创建自己的登录页并重定向未验证客户端的  URL 。您还必须创建自己的帐户查找方案。使用  ASP .NET ，要对  Web.config  文件进行相应的配置   。

 

四、实用要求

(1) 、服务器均为支持.NET框架的WINDOWS系列服务器；

(2) 、客户端浏览器类型为使用Internet Explore内核的浏览器；

(3) 、用户数量没有限制，位置不能确定，用户名及密码均由用户自己控制；

(4) 、应用程序是基于Internet的，而不局限于Intranet中；

(5) 、网站应该是交互式网站；

(6) 、要保护的数据的敏感度较高，需要较强的安全性，防止用户数据流失；

(7) 、要求安装设置较为方便，具有较强的伸缩性；

(8) 、要求限制某些区域仅供注册用户使用，而另一些区域“仅限管理员使用” 。

 

五、选择的身份验证

匿名身份验证不能提供有效的安全性，不需要用户进行身份验证，不能实现实际网站中的限制 某些区域仅供注册用户使用，而另一些区域“仅限管理员使用”。

基本身份验证要求使用用户具有  Windows NT  域或  Active Directory  帐户，不能满足实际网站中“用户数量 没有限制，位置不能确定，用户名及密码均由用户自己控制”的要求。

简要身份验证要求使用用户在  Active Directory  中存储有  Windows  帐户，还要求所有的客户端均使用  .NET  平台或  Internet Explorer 5.x 。不能满足实际网站中“用户数量 没有限制，位置不能确定，用户名及密码均由用户自己控制”的要求；以及“客户端可以使用WindowsXX平台,而不限于  .NET  平台”的要求。

集成  Windows  身份验证要求使用用户具有  Windows NT  域或  Active Directory  帐户，还要求应用程序运行于  Intranet  上，不能满足 实际网站中“ 用户数量没有限制，位置不能确定，用户名及密码均由用户自己控制 ”以及“ 应用程序是基于Internet的，而不局限于Intranet中 ”的要求。

证书身份验证需要将客户端证书物理部署在客户端工作站中，还需管理客户端的证书，这样成本比较高，超过了增加安全性所获得的价值。

Passport  身份验证要求使用用户已经注册了一个 .NET Passport ，用注册的 .NET Passport 帐号和密码进行登陆，这样就限制了用户。使用 Passport 身份验证要求站点注册 Passport 服务，这需要站点支付服务费用。

表单身份验证可以满足实际网站的所有要求，而且成本不高，所以我们选择表单身份验证。

六、选择的身份验证的实现

基于 ASP.NET 实现表单身份验证的步骤：

1、              创建自己的登陆页并 并重定向未验证客户端的  URL

2、              创建自己的帐户查找方案和实现用户身份验证代码。

3、              配置 IIS 为匿名身份验证

4、              配置 ASP.NET 应用程序的 web.config 文件

5、              使用 Cookie 来维护用户在各个请求之间的标识。要使站点真正安全，唯一的方法是站点内的所有通讯都使用 SSL( 安全套接字层 ) 来保护通道。但是由于 SSL 必须执行额外的加密步骤，性能会明显的下降。我们可以使用在 ASP.NET 中使服务器定期重生成 Cookie 来以防有人非法使用别人的 Cookie 。