对于许多ASP.NET开发人员而言，共享资源的访问是一个重大挑战，当开发Web表单和Web服务时就会遇到这样的挑战。微软公司的.NET拥有全新的用户授权和认证措施，大多数与安全相关的文章和书籍都用相当的篇幅解释表单认证，但是，与IIS、网络和操作系统安全相结合来理解ASP.NET安全架构是提供最佳解决方案的关健。

　　（图1）

　　图1描述了由IIS和ASP.NET提供的基本安全表示，它与ASP安全相比有根本不同。上面的图来自MSDN的网站。当有Web请求发生时，下面的事件会依次发生。

　　1、用户发出HTTP请求。

　　2、当Web请求发生时，它会由以SYSTEM帐户运行的IIS获得。SYSTEM帐户的功能非常强大，而且拥有所有类型的权限。IIS根据选择的认证类型进行认证，并为每名经过认证的用户创建一个访问令牌。如果选择了了匿名认证，它就会为该匿名用户创建一个访问令牌，缺省情况下是IUSR_MACHINE。另外，ISS还根据配置的授权类型进行认证。例如，IIS能够配置得只接受来自特定IP地址的请求。

　　3、IIS将请求和被认证用户的Windows访问令牌传递给aspnet_isepi.dll，这是一个注册为处理.aspx URL的ISAPI扩展。Aspnet_isepi.dll是一个IIS模块，是IIS和ASP.NET运行时间环境之间的一座桥。Aspnet_isapi通过命名管道向工作者进程转发该请求。

　　4、该工作者进程是托管着CLR的aspnet_wp.exe。缺省情况下，工作者进程以ASPNET帐户运行。当安装ASP.NET框架时，系统会创建该本地帐户。与功能强大的SYSTEM帐户不同的是，ASPNET帐户的功能十分有限。ASP.NET根据其认证配置对请求者进行认证。认证以XML格式配置在该项目的web.config文件中。如果ASP.NET被配置为Windows认证，它会接受任何来自IIS的令牌，而不会进行其它认证。另外，ASP.NET还授权对请求的资源和文件的访问。例如，FileAuthorizationModel可以用来检查用户是否具有访问请求的资源所需要的权限。对于Windows认证而言，用户的访问令牌为ACL。

　　5、如果整个过程发展到了这一步，应用软件就会使用特定的身份访问资源。缺省情况下，ASPNET进程帐户提供这一身份。但是，如果允许模仿，可以使用用户原来的身份或对模仿进行配置，使应用程序能够以特定的身份运行。

　　既然安全措施已经阐明，在假设NTFC的权限被设置为网络资源的情况下，用户就可以访问数据了。在进一步向前发展之前，有二个重要问题需要解决。一个是指定和定义访问UNC共享上文件和文件夹的任务，换句话说，也就是访问网络上共享的文件和文件夹。另一个问题是决定用来完成资源访问任务的身份。为了完成第一个任务，需要首先完成第二个任务。

　　有几种方法可以用来访问网络资源：

　　·使用ASP.NET进程身份

　　·使用匿名用户帐户

　　·使用LogonUser API

　　·使用服务性的组件（企业服务）

　　使用ASP.NET进程身份似乎有很明显的缺陷。缺省情况下，当应用程序试着访问资源时，ASP.NET进程身份提供一个身份（ASPNET）。最简单的解决方案是创建一个具有与远程计算机上相匹配的用户名和密码的本地帐户。大多数企业都会有庞大的内联网，因此这一方法是不切实际的。另外，知道是谁在访问资源也是非常重要的。尽管该方法足以访问网络资源，但效率不够高；第二个方法是使用匿名帐户，例如IUSR_MACHINE。与上面的原因相同，这种方法的效率显然也不高；第三种方法是使用LogonUser API，这种方法要求通过调用Win32 LogonUser API模仿一个特定的身份，还可以通过配置ASP.NET项目web.config文件中的＜identity＞元素进行模仿。据MSDN上的一篇文章称，不建议用户使用以上这些方法，应当避免在Windows 2000服务器上使用它们，因为它们要求向ASP.NET帐户进程授予“作为操作系统一部分运行”的权限，从而极大地降低了web应用程序的安全性。因此，该方法也不理想。最后，也是最可行的解决该问题的方法是使用配置为作为用于访问网络资源固定身份运行的服务性组件。这种方法听起来令人胆怯，但它是目前最好的解决方案，它的架构如下图所示：