Web 应用程序的访问权限

Web 应用程序的访问权限2007-04-19 11:38像任何应用程序一样，Web 应用程序需要访问不同的系统资源（如文件或数据库）。这些资源通常由授予不同用户和组的访问级别保护。

在 Web 应用程序中，它可能不是请求直接访问的应用程序用户。相反，用户使用浏览器与 Web 应用程序进行通信，然后由 Web 应用程序请求资源。此间接访问会带来访问权限问题。

有几种策略可用于管理 Web 应用程序中的访问权限。以下几节将提供每个选项的概述。主题中的链接指向包含更多信息的主题。

通过 Windows 集成安全性进行访问
如果您的 Web 应用程序运行在 Intranet 环境中（即所有用户都运行 Windows 并在同一防火墙之后），则应用程序可以使用 Windows 集成安全性访问资源。在此策略中，所有用户一登录到 Windows 就对他们进行身份验证。身份验证进程将生成一个包含该用户信息的标记。（标记不包含用户的凭据，仅包含指示已对该用户进行身份验证的代码。）在请求本地资源时，Web 应用程序可以使用此标记。例如，已登录的用户在 Internet Explorer 中请求 Web 窗体页。请求将被传递到 Internet 信息服务 (IIS)，然后传递到 ASP.NET，ASP.NET 可以使用用户的身份验证标记请求访问服务器计算机上的文件。

Windows 集成安全性通常是 Web 访问权限的最安全选项。如果在您的应用程序中是可行的，则应该将应用程序配置为使用此选项。

有关详细信息，请参见 ASP.NET 身份验证。

使用 ASP.NET 用户帐户的匿名访问
在大多数应用程序中，用户通常匿 梦?Web 应用程序（即最初他们不提供身份验证凭据）。在这种情况下，Web 应用程序必须采用（模拟）它可以用于请求资源的某个标识。

默认情况下，当 ASP.NET 允许使用匿名访问时，应用程序运行在特殊的本地（不是域）帐户的上下文中。用户上下文因操作系统而异。在 Windows 2000 和 Windows XP 中，应用程序运行在名为 ASPNET 的帐户之下。在 Windows Server 2003 中，用户上下文称为 NETWORK SERVICE。这些用户帐户是在 .NET Framework 安装过程中创建的，它具有唯一的不易破解的密码，并仅被授予有限的权限。ASPNET 或 NETWORK SERVICE 用户只能访问运行 Web 应用程序所需的特定文件夹，如 Web 应用程序存储已编译文件的 /bin 目录。

注意 IIS 具有将匿名用户映射到特定本地用户或域用户的类似机制。您可以使用 IIS 工具重新映射应用程序中所有文件的匿名访问，而不仅仅映射 ASP.NET 文件（Web 窗体页和控件）。有关详细信息，请参见 Microsoft Internet Information Server 安全性概述。
如果您的 Web 应用程序需要访问 Web 服务器计算机上的其他资源，则可以根据需要向 ASPNET 或 NETWORK SERVICE 用户授予权限。例如，如果应用程序需要将一个文件写入目录，则需要将写入权限显式授予该目录中的 ASPNET 或 NETWORK SERVICE 帐户。

或者，您可以在请求资源时为要使用的 ASP.NET 指定另一个用户标识。您可以指定以其名义发出请求的用户名（本地用户或域用户）。有关详细信息，请参见 ASP.NET 进程标识。有关详细信息，请参见 <processModel> 元素。或者您可以指定 ASP.NET 改为在系统（管理员）上下文中运行。

警告 在系统上下文中运行 ASP.NET 应用程序，就允许这些应用程序使用服务器上的管理权限运行。如果用户可以控制您的应用程序，那么他们就可以随意访问服务器上的许多重要资源。
默认情况下，您使用默认的用户上下文无法访问某些资源，因为它们要求访问需要管理级别特权的资源。例如，如果您的应用程序需要使用 System.Diagnostics 命名空间中的方法创建新的事件日志类别，如果它运行在 ASPNET 或 NETWORK SERVICE 用户的上下文中，则无法创建新的事件日志类别。在这种情况下，您需要更改应用程序上下文，或者进行更改使 ASP.NET 用户帐户可以访问事件日志。

警告 要将进程标识设置为特定用户名，以取代 ASPNET 或 NETWORK SERVICE 用户标识，您提供的用户名和密码都必须存储在 machine.config 文件中。存储任何凭据信息都会有安全风险，其原因是：如果有人设法访问 machine.config，或者，如果他们获得了 Web 服务器计算机上的管理员特权，就有可能读取或更改此私有信息。要让 machine.config 文件对于管理员用户以外的其他所有用户都是只读的。有关在 machine.config 文件中设置用户名和密码的详细信息，请参见 <processModel> 元素。
使用提供的凭据进行访问
您的 Web 应用程序还可以通过在运行时提供凭据来请求资源。这种方式无法用于请求所有资源，但是可以用于请求接受用户名和密码的资源，例如，接受连接字符串的数据库。

安全说明 使用连接字符串（称为“混合模式”）访问 SQL Server 不如使用 Windows 集成安全性安全。如果 Web 服务器和 SQL 服务器运行在同一台计算机上，则您可以轻松而安全地使用 Windows 集成安全性。
使用“基本”、“摘要式”或 Forms 身份验证，您可以直接从用户获得凭据。例如，当用户要访问您站点的受限制部分时，您的应用程序可能提示用户输入用户名和密码。有关身份验证的详细信息，请参见 IIS 身份验证和 ASP.NET 身份验证。

安全说明 在应用程序中提示用户输入用户名和密码是一种潜在的安全威胁。凭据信息必须从浏览器传输到服务器上，而普通的 HTTP 传输未加密。为了获得最佳安全性，在应用程序中提示用户提供凭据时，应使用安全套接字层 (SSL)，它在将信息从浏览器发送到服务器之前，对其进行加密。有关详细信息，请参见使用安全套接字层。
在从用户获取凭据后，您可以在请求资源时传递它们。对于数据库，在打开连接时通常您可以将用户名和密码插入连接字符串。对于其他资源，您可以调用名为 LogonUser 的 Windows API，它为您提供的信息建立用户上下文并使用该上下文请求对资源的访问。

有时，与您的应用程序一起直接存储凭据更方便。例如，可以创建将用户名和密码硬编码到其中的数据库连接字符串。有关详细信息，请参见使用显式凭据访问 SQL Server。

安全说明 建议在一般情况下不要将凭据硬编码到应用程序中，因为凭据信息是可以读取的，即使它已经被编译也是如此。即使您确实将任何用户凭据信息硬编码到应用程序中，也决不应使用给用户提供最低资源访问特权以外的其他任何特权的用户名。
如果确实您选择将凭据作为应用程序的一部分进行存储，则应该努力保护它们。一种可能性是使用“数据保护 API”(DPAPI)。有关详细信息，请参见 MSDN Online (http://msdn.microsoft.com/librar ... api.asp?frame=true) 上的技术文章“Windows 数据保护”。

访问远程资源（委托）
有时，您的应用程序所需的资源位于计算机上，而不是 Web 服务器上。对于某些资源（如数据库），建议这样做。在这种情况下，应用程序必须代表用户向远程计算机发出请求。此过程称为“委托”。

就像对资源的任何请求一样，向远程计算机发出的请求也必须包含适当的凭据。如果您的应用程序允许匿名访问，则 IIS 和 ASP.NET 没有用户的凭据，因此在委托过程中无法使用它们访问远程资源。在这种情况下，您可以：

通过提示输入用户凭据来获取显式用户凭据。然后，应用程序可以根据需要将它们传递到远程计算机。如果您正在使用 SQL Server，则可以将用户凭据添加到连接字符串中。有关示例，请参见使用显式凭据访问 SQL Server。
将 Web 应用程序的用户上下文从 ASPNET 或 NETWORK SERVICE 用户更改为可以将其凭据传递到远程计算机的特定域用户。有关示例，请参见使用映射的 Windows 域用户访问 SQL Server。
注意 如果您在同一台计算机上运行浏览器和 Web 服务器，并且是以域用户身份登录的，就可以委托到远程计算机，因为 IIS 计算机具有您的凭据。虽然这种情况常见于测试，但在生产中非常少见。如有可能，请始终通过在不同的计算机上分别运行浏览器和 Web 服务器来测试访问权限。