asp.net身份验证方式介绍

如果ASP.NET针对Windows身份验证进行配置，则ASP.NET依靠IIS，利用配置好的身份验证模式对其客户端进行身份验证。IIS通过检查特定应用程序的元数据库设置来确定其身份验证模式。成功验证某个用户的身份后，IIS将代表经过身份验证的用户的Windows令牌传递给宿主ASP.NET的ASP.NET辅助进程(w3wp.exe)。如果应用程序使用在IIS中配置的虚拟目录来支持匿名访问，该令牌代表匿名Internet用户帐户；否则，该令牌代表经过身份验证的用户。

IIS支持以下身份验证模式：

匿名。如果不需要对客户端进行身份验证（或者使用自定义身份验证机制，如窗体身份验证），则可将IIS配置为允许匿名访问。在该事件中，IIS创建一个Windows令牌来表示具有相同匿名（或客人）帐户的所有匿名用户。默认的匿名帐户是IUSR_MACHINENAME，其中MACHINENAME是安装期间指定的计算机的NetBIOS名称。

基本。基本身份验证要求用户以用户名和密码的形式提供凭据来证明他们的身份。基本身份验证基于Internet标准RFC2617，所有常用浏览器都支持它。用户的凭据以未加密的Base64编码格式从浏览器传送到Web服务器。为了更好保护这些凭据，只要在使用基本身份验证同时再使用安全套接字层(SSL)即可。由于Web服务器包含未加密的用户凭据，因此ASP.NET应用程序可以模拟调用方并使用他们的凭据来访问网络资源。

集成的Windows。集成的Windows身份验证（以前称为NTLM，也称为WindowsNT质询/应答身份验证，WindowsNTChallenge/Response）是使用Kerberosv5身份验证还是NTLM身份验证，取决于客户端和服务器的配置。服务器与客户端协商确定要使用的协议。如果满足以下条件，则使用Kerberos身份验证：

ASP.NETWeb应用程序正在NetworkService帐户或自定义域帐户下运行。如果应用程序在本地帐户（如Windows2000Server上的ASPNET帐户）上运行，则使用NTLM身份验证。

域帐户的ActiveDirectory中有一个服务主要名称(SPN)，该域帐户用于运行客户端进行身份验证所使用的服务。

客户端计算机和服务器计算机至少需要运行Windows2000Server，且处在相同的（即信任的）Windows域中。

注默认情况下，对于WindowsServer2003操作系统启用集成Windows身份验证。然而，如果WindowsServer2003ServicePack1(SP1)作为WindowsServer2003操作系统整合安装的一部分进行安装，则默认情况下禁用集成Windows身份验证。如果使用SP1升级WindowsServer2003，则集成Windows身份验证的设置与其WindowsServer2003设置相同。

应该使用集成Windows身份验证而不是基本身份验证，因为前者避免了通过网络传输用户凭据。由于Kerberosv5身份验证支持相互身份验证，因此用户还可以对正在连接的服务器进行身份验证。

集成Windows身份验证最适合于Intranet环境，其中的客户端计算机和Web服务器计算机都是相同（即信任的）域的一部分。

NTLM是用于WindowsNT和Windows2000Server工作组环境的身份验证协议。它还用在必须对WindowsNT系统进行身份验证的混合Windows2000ActiveDirectory域环境中。当Windows2000Server转换为不存在下层WindowsNT域控制器的本机模式时，禁用NTLM。然后Kerberosv5变成企业级的默认身份验证协议。

NTLM身份验证机制

图1显示NTLM协议。

下面概述质询/应答机制：

用户请求访问。用户尝试通过提供用户凭据登录到客户端。登录前，客户端计算机缓存密码的哈希值并放弃密码。客户端向服务器发送一个请求，该请求包括用户名以及纯文本格式的请求。

服务器发送质询消息。服务器生成一个称为质询的16字节随机数（即NONCE），并将它发送到客户端。

客户端发送应答消息。客户端使用由用户的密码生成的一个密码哈希值来加密服务器发送的质询。它以应答的形式将这个加密的质询发回到服务器。

服务器将质询和应答发送到域控制器。服务器将用户名、原始质询以及应答从客户端计算机发送到域控制器。

域控制器比较质询和应答以对用户进行身份验证。域控制器获取该用户的密码哈希值，然后使用该哈希值对原始质询进行加密。接下来，域控制器将加密的质询与客户端计算机的应答进行比较。如果匹配，域控制器则发送该用户已经过身份验证的服务器确认。

服务器向客户端发送应答。假定凭据有效，服务器授予对所请求的服务或资源的客户端访问权。

与NTLM身份验证相比，Kerberos身份验证具有以下优势：

相互身份验证。当客户端使用Kerberosv5协议对特定服务器上的特定服务进行身份验证，Kerberos为客户端提供网络上恶意代码不会模拟该服务的保证。

委托支持。使用Kerberos身份验证对客户端进行身份验证的服务器可以模拟这些客户端，并使用该客户端的安全上下文访问网络资源。

性能。Kerberos身份验证提供优于NTLM身份验证的改进的性能。

简化的信任管理。具有多个域的网络不再需要一组复杂的显式、点对点信任关系。

互操作性。Microsoft实现的Kerberos协议基于向Internet工程任务组(IETF)推荐的标准跟踪规范。因此，Windows2000中协议的实现为与其他网络的互操作奠定了基础（其中Kerberos版本5用于身份验证）。

Kerberos身份验证机制

图2显示Kerberos身份验证协议的简化视图。

当客户端对网络服务进行身份验证之后，Kerberosv5协议遵循以下步骤：

客户端从KDC请求TGT。用户试图通过提供用户凭据登录到客户端。客户端计算机上的Kerberos服务向密钥发行中心(KDC)发送一个Kerberos身份验证服务请求。该请求包含用户名、请求票证授予票证（ticket-grantingticket，TGT）所获取的服务信息，以及使用用户的长期密钥（即密码）加密的时间戳。

注在Windows2000Server或WindowsServer2003操作系统上，域控制器充当KDC，而ActiveDirectory宿主安全帐户数据库。

身份验证服务发送加密的TGT和会话密钥。KDC为来自ActiveDirectory的用户获取长期密钥（即密码），然后解密随请求一起传送的时间戳。如果该时间戳有效，则用户是真正的用户。KDC身份验证服务创建一个登录会话密钥，并使用用户的长期密钥对该副本进行加密。然后，该身份验证服务创建一个TGT，它包括用户信息和登录会话密钥。最后，该身份验证服务使用自己的密钥加密TGT，并将加密的会话密钥和加密的TGT传递给客户端。

客户端从TGT请求服务器访问。客户端使用其长期密钥（即密码）解密登录会话密钥，并在本地缓存它。此外，客户端还将加密的TGT存储在它的缓存中。访问网络服务时，客户端向KDC票证授予服务（ticket-grantingservice，TGS）发送一个包含信息的请求，这些信息包括用户名、使用用户登录会话密钥加密的验证者消息、TGT，以及用户想访问的服务（和服务器）名称。

TGS发送加密的会话密钥和票证。KDC上的TGS使用自己的密钥解密KDC并提取登录会话密钥。它使用该登录会话密钥解密验证者消息（通常是时间戳）。如果验证者消息成功解密，TGS从TGT提取用户信息，并使用用户信息创建一个用于访问该服务的服务会话密钥。它使用该用户的登录会话密钥对该服务会话密钥的一个副本进行加密，创建一个具有服务会话密钥和用户信息的服务票证，然后使用该服务的长期密钥（密码）对该服务票证进行加密。然后，TGS将加密的服务会话密钥和服务票证添加到客户端。

客户端发送服务票证。客户端访问服务时，向服务器发送一个请求。该请求包含验证者消息（时间戳），该消息使用服务会话密钥和服务票证进行加密。

服务器发送加密的时间戳以进行客户端验证。服务器解密服务票证并提取服务会话密钥。通过使用服务会话密钥，服务器解密验证者消息（时间戳）并计算它。如果验证者通过测试，则服务器使用服务会话密钥对验证者（时间戳）进行加密，然后将验证者传回到客户端。客户端解密时间戳，如果该时间戳与原始时间戳相同，则该服务是真正的，客户端继续连接。

服务的主要名称

Kerberosv5身份验证协议之所以使用服务的主要名称(SPN)，原因如下：

支持相互身份验证。

允许一个客户端请求票证，进而允许该客户端与特定服务通讯。

例如，如果某个客户端需要获得一个票证，并对在侦听端口4766运行的计算机(MyServer)上的特定服务(MyService)进行身份验证，则该客户端使用根据该信息构造的名称从KDC请求一个票证，如下所示：

MyService/MyServer:4766

在ActiveDirectory中注册的SPN在该名称和运行所请求的服务的域帐户之间维护一个映射。通过使用该机制，恶意用户难以在网络上模拟服务。恶意用户必须禁用实际服务并从该网络移除实际服务器。然后，恶意用户必须向网络中添加一台同名的新计算机并公开重复的服务。由于客户端使用具有相互身份验证的Kerberosv5协议，因此该客户端将无法使用重复的服务，除非它可以提供配置实际服务进行运行的域帐户的密码。

与NTLM身份验证相比，Kerberos身份验证具有以下优势：

相互身份验证。当客户端使用Kerberosv5协议对特定服务器上的特定服务进行身份验证，Kerberos为客户端提供网络上恶意代码不会模拟该服务的保证。

委托支持。使用Kerberos身份验证对客户端进行身份验证的服务器可以模拟这些客户端，并使用该客户端的安全上下文访问网络资源。

性能。Kerberos身份验证提供优于NTLM身份验证的改进的性能。

简化的信任管理。具有多个域的网络不再需要一组复杂的显式、点对点信任关系。

互操作性。Microsoft实现的Kerberos协议基于向Internet工程任务组(IETF)推荐的标准跟踪规范。因此，Windows2000中协议的实现为与其他网络的互操作奠定了基础（其中Kerberos版本5用于身份验证）。

Kerberos身份验证机制

图2显示Kerberos身份验证协议的简化视图。

当客户端对网络服务进行身份验证之后，Kerberosv5协议遵循以下步骤：

客户端从KDC请求TGT。用户试图通过提供用户凭据登录到客户端。客户端计算机上的Kerberos服务向密钥发行中心(KDC)发送一个Kerberos身份验证服务请求。该请求包含用户名、请求票证授予票证（ticket-grantingticket，TGT）所获取的服务信息，以及使用用户的长期密钥（即密码）加密的时间戳。

注在Windows2000Server或WindowsServer2003操作系统上，域控制器充当KDC，而ActiveDirectory宿主安全帐户数据库。

身份验证服务发送加密的TGT和会话密钥。KDC为来自ActiveDirectory的用户获取长期密钥（即密码），然后解密随请求一起传送的时间戳。如果该时间戳有效，则用户是真正的用户。KDC身份验证服务创建一个登录会话密钥，并使用用户的长期密钥对该副本进行加密。然后，该身份验证服务创建一个TGT，它包括用户信息和登录会话密钥。最后，该身份验证服务使用自己的密钥加密TGT，并将加密的会话密钥和加密的TGT传递给客户端。

客户端从TGT请求服务器访问。客户端使用其长期密钥（即密码）解密登录会话密钥，并在本地缓存它。此外，客户端还将加密的TGT存储在它的缓存中。访问网络服务时，客户端向KDC票证授予服务（ticket-grantingservice，TGS）发送一个包含信息的请求，这些信息包括用户名、使用用户登录会话密钥加密的验证者消息、TGT，以及用户想访问的服务（和服务器）名称。

TGS发送加密的会话密钥和票证。KDC上的TGS使用自己的密钥解密KDC并提取登录会话密钥。它使用该登录会话密钥解密验证者消息（通常是时间戳）。如果验证者消息成功解密，TGS从TGT提取用户信息，并使用用户信息创建一个用于访问该服务的服务会话密钥。它使用该用户的登录会话密钥对该服务会话密钥的一个副本进行加密，创建一个具有服务会话密钥和用户信息的服务票证，然后使用该服务的长期密钥（密码）对该服务票证进行加密。然后，TGS将加密的服务会话密钥和服务票证添加到客户端。

客户端发送服务票证。客户端访问服务时，向服务器发送一个请求。该请求包含验证者消息（时间戳），该消息使用服务会话密钥和服务票证进行加密。

服务器发送加密的时间戳以进行客户端验证。服务器解密服务票证并提取服务会话密钥。通过使用服务会话密钥，服务器解密验证者消息（时间戳）并计算它。如果验证者通过测试，则服务器使用服务会话密钥对验证者（时间戳）进行加密，然后将验证者传回到客户端。客户端解密时间戳，如果该时间戳与原始时间戳相同，则该服务是真正的，客户端继续连接。

服务的主要名称

Kerberosv5身份验证协议之所以使用服务的主要名称(SPN)，原因如下：

支持相互身份验证。

允许一个客户端请求票证，进而允许该客户端与特定服务通讯。

例如，如果某个客户端需要获得一个票证，并对在侦听端口4766运行的计算机(MyServer)上的特定服务(MyService)进行身份验证，则该客户端使用根据该信息构造的名称从KDC请求一个票证，如下所示：

MyService/MyServer:4766

在ActiveDirectory中注册的SPN在该名称和运行所请求的服务的域帐户之间维护一个映射。通过使用该机制，恶意用户难以在网络上模拟服务。恶意用户必须禁用实际服务并从该网络移除实际服务器。然后，恶意用户必须向网络中添加一台同名的新计算机并公开重复的服务。由于客户端使用具有相互身份验证的Kerberosv5协议，因此该客户端将无法使用重复的服务，除非它可以提供配置实际服务进行运行的域帐户的密码。

IIS向ASP.NET传递代表经过身份验证的用户或匿名用户帐户的令牌。该令牌在一个包含在IPrincipal对象中的IIdentity对象中维护，IPrincipal对象进而附加到当前Web请求线程。可以通过HttpContext.User属性访问IPrincipal和IIdentity对象。这些对象和该属性由身份验证模块设置，这些模块作为HTTP模块实现并作为ASP.NET管道的一个标准部分进行调用，如图3所示。

ASP.NET管道模型包含一个HttpApplication对象、多个HTTP模块对象，以及一个HTTP处理程序对象及其相关的工厂对象。HttpRuntime对象用于处理序列的开头。在整个请求生命周期中，HttpContext对象用于传递有关请求和响应的详细信息。

有关ASP.NET请求生命周期的详细信息，请参阅"ASP.NETLifeCycle"，网址是http://msdn2.microsoft.com/library/ms227435(en-US,VS.80).aspx。

身份验证模块

ASP.NET2.0在计算机级别的Web.config文件中定义一组HTTP模块。其中包括大量身份验证模块，如下所示：

<httpModules><addname="WindowsAuthentication"type="System.Web.Security.WindowsAuthenticationModule"/><addname="FormsAuthentication"type="System.Web.Security.FormsAuthenticationModule"/><addname="PassportAuthentication"type="System.Web.Security.PassportAuthenticationModule"/></httpModules>

只加载一个身份验证模块，这取决于该配置文件的authentication元素中指定了哪种身份验证模式。该身份验证模块创建一个IPrincipal对象并将它存储在HttpContext.User属性中。这是很关键的，因为其他授权模块使用该IPrincipal对象作出授权决定。

当IIS中启用匿名访问且authentication元素的mode属性设置为none时，有一个特殊模块将默认的匿名原则添加到HttpContext.User属性中。因此，在进行身份验证之后，HttpContext.User绝不是一个空引用（在VisualBasic中为Nothing）。

WindowsAuthenticationModule

如果Web.config文件包含以下元素，则激活WindowsAuthenticationModule类。

<authenticationmode="Windows"/>

WindowsAuthenticationModule类负责创建WindowsPrincipal和WindowsIdentity对象来表示经过身份验证的用户，并且负责将这些对象附加到当前Web请求。

对于Windows身份验证，遵循以下步骤：

• WindowsAuthenticationModule使用从IIS传递到ASP.NET的Windows访问令牌创建一个WindowsPrincipal对象。该令牌包装在HttpContext类的WorkerRequest属性中。引发AuthenticateRequest事件时，WindowsAuthenticationModule从HttpContext类检索该令牌并创建WindowsPrincipal对象。HttpContext.User用该WindowsPrincipal对象进行设置，它表示所有经过身份验证的模块和ASP.NET页的经过身份验证的用户的安全上下文。

• WindowsAuthenticationModule类使用P/Invoke调用Win32函数并获得该用户所属的Windows组的列表。这些组用于填充WindowsPrincipal角色列表。

• WindowsAuthenticationModule类将WindowsPrincipal对象存储在HttpContext.User属性中。随后，授权模块用它对经过身份验证的用户授权。

  注：DefaultAuthenticationModule类（也是ASP.NET管道的一部分）将Thread.CurrentPrincipal属性设置为与HttpContext.User属性相同的值。它在处理AuthenticateRequest事件之后进行此操作。

授权模块

WindowsAuthenticationModule类完成其处理之后，如果未拒绝请求，则调用授权模块。授权模块也在计算机级别的Web.config文件中的httpModules元素中定义，如下所示：

<httpModules><addname="UrlAuthorization"type="System.Web.Security.UrlAuthorizationModule"/><addname="FileAuthorization"type="System.Web.Security.FileAuthorizationModule"/><addname="AnonymousIdentification"type="System.Web.Security.AnonymousIdentificationModule"/></httpModules>

UrlAuthorizationModule

调用UrlAuthorizationModule类时，它在计算机级别或应用程序特定的Web.config文件中查找authorization元素。如果存在该元素，则UrlAuthorizationModule类从HttpContext.User属性检索IPrincipal对象，然后使用指定的动词（GET、POST等）来确定是否授权该用户访问请求的资源。

FileAuthorizationModule

接下来，调用FileAuthorizationModule类。它检查HttpContext.User.Identity属性中的IIdentity对象是否是WindowsIdentity类的一个实例。如果IIdentity对象不是WindowsIdentity类的一个实例，则FileAuthorizationModule类停止处理。

如果存在WindowsIdentity类的一个实例，则FileAuthorizationModule类调用AccessCheckWin32函数（通过P/Invoke）来确定是否授权经过身份验证的客户端访问请求的文件。如果该文件的安全描述符的随机访问控制列表(DACL)中至少包含一个Read访问控制项(ACE)，则允许该请求继续。否则，FileAuthorizationModule类调用HttpApplication.CompleteRequest方法并将状态码401返回到客户端。

安全上下文

.NETFramework使用以下两个接口封装Windows令牌和登录会话：

• System.Security.Principal.IPrincipal

• System.Security.Principal.IIdentity（它公开为IPrincipal接口中的一个属性。）

HttpContext.User

在ASP.NET中，用WindowsPrincipal和WindowsIdentity类表示使用Windows身份验证进行身份验证的用户的安全上下文。使用Windows身份验证的ASP.NET应用程序可以通过HttpContext.User属性访问WindowsPrincipal类。

要检索启动当前请求的Windows经过身份验证的用户的安全上下文，使用以下代码：

usingSystem.Security.Principal;...//Obtaintheauthenticateduser"sIdentityWindowsPrincipalwinPrincipal=(WindowsPrincipal)HttpContext.Current.User;

WindowsIdentity.GetCurrent

WindowsIdentity.GetCurrent方法可用于获得当前运行的Win32线程的安全上下文的标识。如果不使用模拟，线程继承IIS6.0（默认情况下的NetworkService帐户）上进程的安全上下文。

该安全上下文在访问本地资源时使用。通过使用经过身份验证的初始用户的安全上下文或使用固定标识，您可以使用模拟重写该安全上下文。

要检索运行应用程序的安全上下文，使用以下代码：

usingSystem.Security.Principal;...//Obtaintheauthenticateduser"sidentity.WindowsIdentitywinId=WindowsIdentity.GetCurrent();WindowsPrincipalwinPrincipal=newWindowsPrincipal(winId);

Thread.CurrentPrincipal

ASP.NET应用程序中的每个线程公开一个CurrentPrincipal对象，该对象保存经过身份验证的初始用户的安全上下文。该安全上下文可用于基于角色的授权。

要检索线程的当前原则，使用以下代码：

usingSystem.Security.Principal;...//Obtaintheauthenticateduser"sidentityWindowsPrincipalwinPrincipal=(WindowsPrincipal)Thread.CurrentPrincipal();

表1显示从各种标识属性获得的结果标识，当您的应用程序使用Windows身份验证且IIS配置为使用集成Windows身份验证时，可以从ASP.NET应用程序使用这些标识属性。

表1：线程公开的CurrentPrincipalObject

模拟

ASP.NET应用程序可以使用模拟来执行操作，使用经过身份验证的客户端或特定Windows帐户的安全上下文来访问资源。

初始用户模拟

要模拟初始（经过身份验证的）用户，请在Web.config文件中使用以下配置：

<authenticationmode="Windows"/><identityimpersonate="true"/>

使用该配置，ASP.NET始终模拟经过身份验证的用户，且所有资源访问均使用经过身份验证的用户的安全上下文执行。如果您的应用程序的虚拟目录上启用了匿名访问，则模拟IUSR_MACHINENAME帐户。

要暂时模拟经过身份验证的调用方，将identity元素的impersonate属性设置为false，然后使用以下代码：

usingSystem.Security.Principal;...//Obtaintheauthenticateduser"sidentity.WindowsIdentitywinId=(WindowsIdentity)HttpContext.Current.User.Identity;WindowsImpersonationContextctx=null;try{//Startimpersonating.ctx=winId.Impersonate();//Nowimpersonating.//Accessresourcesusingtheidentityoftheauthenticateduser.}//Preventexceptionsfrompropagating.catch{}finally{//Revertimpersonation.if(ctx!=null)ctx.Undo();}//BacktorunningunderthedefaultASP.NETprocessidentity.

这段代码模拟经过身份验证的初始用户。在HttpContext.Current.User.Identity对象中维护初始用户的标识和Windows令牌。

固定标识模拟

如果需要在应用程序的整个生命周期中模拟相同的标识，可以在Web.config文件中的identity元素上指定凭据。以下示例显示如何模拟名为"TestUser"的Windows帐户。

如果使用该方法，应该对这些凭据进行加密。使用ASP.NET2.0，您可以使用ASP.NETIIS注册工具(Aspnet_regiis.exe)。使用ASP.NET1.1版，您可以使用Aspnet_setreg.exe实用工具。有关该实用工具的详细信息，请参阅http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpgrfaspnetiisregistrationtoolaspnet_regiisexe.asp。

要在ASP.NET应用程序中使用固定标识进行资源访问，可使用Windows2000Server或WindowsServer2003上的identity元素来配置凭据。如果正在运行WindowsServer2003，其中的IIS6.0配置为运行在辅助进程隔离模式下（默认情况），则可通过将ASP.NET应用程序配置为在自定义应用程序池（在特定的域标识下运行）中运行来避免模拟。然后，可以使用指定的域标识访问资源而无需使用模拟。

委托

模拟只提供对本地资源的访问。委托是一个扩展的模拟功能，它允许您使用模拟令牌访问网络资源。

如果应用程序使用Kerberosv5身份验证对其用户进行身份验证，则可使用Kerberos委托在应用程序的各层传递用户标识并访问网络资源。如果应用程序不使用Kerberosv5身份验证，则可使用协议转换切换到Kerberos，然后使用委托传递该标识。

WindowsServer2003中的约束委托需要Kerberos身份验证。如果您的应用程序无法使用Kerberos身份验证对其调用方进行身份验证，您可以使用协议转换从可选的非Windows身份验证模式（如，窗体或证书身份验证）切换到Kerberos身份验证。然后，可使用具有约束委托的Kerberos访问下游网络资源。

约束的和未约束的委托

Windows2000Server上的Kerberos委托是未约束的。ActiveDirectory中配置了委托的服务器可在使用模拟的用户安全上下文的同时访问任何网络资源或网络上的任何计算机。这会带来潜在的安全威胁，尤其是Web服务器遭受恶意用户攻击时。

为了解决该安全问题，WindowsServer2003引入了约束的委托。这使管理员能够在使用模拟的用户安全上下文时准确指定另一个服务器或域帐户可以访问的服务。

配置委托

要使用Kerberos委托，需要适当的ActiveDirectory配置。

要授予Web服务器委托客户端凭据的权限，请按以下方式配置ActiveDirectory：

• 如果在NetworkService帐户下运行应用程序，Web服务器计算机帐户必须在ActiveDirectory中标记为受信任委托。

• 如果在自定义域帐户下运行应用程序，该用户帐户必须在ActiveDirectory中标记为受信任委托。

• 如果应用程序模拟一个用户帐户，请确保应用程序模拟的用户帐户在ActiveDirectory中未标记为"敏感帐户，不能被委托"。

有关协议转换和约束委托的详细信息，请参阅HowTo:UseProtocolTransitionandConstrainedDelegationinASP.NET2.0。

本文地址： asp.net身份验证方式介绍

相关文章

• .net让Oracle与ASP.NET实现无缝连接（oracleasp）
• .net利用MSSQL连接ASP.NET的办法探索（mssql 连接asp）
• 解决ASP连接MySQL报错的排查方法（asp连接mysql报错）
• 介绍几个ASP.NET中容易忽略但却很重要的方法函数
• Asp.Net重定向必须要知道的一些资料
• asp.net大文件上传控件
• ASP.NET输出PNG图片时出现GDI+一般性错误的解决方法
• asp.net权限管理分析
• asp.net(C#)动态添加非ASP的标准html控件（如添加Script标签）
• asp.net结合YUI3.0小示例
• ASP.NET页面之间传递值方式优缺点比较
• asp.net中利用ajax获取动态创建表中文本框的值
• asp.net动态生成rdlc报表(原创)
• asp.net学习之路项目整体框架简单的搭建
• 在Asp.net网页上写读Cookie的两种不同语法介绍
• asp.net子窗体与父窗体交互实战分享
• .Net中导出数据到Excel(asp.net和winform程序中)
• ASP.NET笔记之Session、http、web开发原则、xss漏洞的详细介绍
• Asp.net中DataTable导出到Excel的方法介绍
• ASP.NET中DataTable与DataSet之间的转换示例
• asp.net图片上传实例
• ASP.NET单选按钮控件RadioButton常用属性和方法介绍
• ASP.NET数据库缓存依赖实例分析