ASP.NET应用程序的安全模型

.NET Web 应用程序

Web 应用程序在布置上可以看作逻辑层与物理层。

逻辑层部署模型

逻辑应用程序体系结构将任何系统都视为一组相互协作的服务，这些服务分为以下几层：

此逻辑体系结构视图的意义的价值在于将普遍存在于任何系统中的各种服务区分开来、确保了适当的分离以及促成各层之间的接口定义。这种分离可以使您在实现每个逻辑层时更为谨慎地进行体系结构和设计选择，从而构建出更易于维护的应用程序。

现将各逻辑辑层描述如下：

系统内各服务类型的逻辑分类既与实现这些服务的组件的可能的物理分布相关，又相对独立于它们的物理分布。

可以在任何聚合级别上标识逻辑层，具体来说，可以对整个系统（在系统环境上下文和外部交互中）标识逻辑层，也可以对系统中所含的任何子系统标识逻辑层。记住这一点也很重要。例如，承载 Web 服务的每个远程节点由用户服务（处理传入的请求和消息）、业务服务和数据服务组成。

物理部署模型

前面所述的三个逻辑服务层并不意味着存在特定数量的物理层。所有这三种逻辑服务在物理上可能位于同一台计算机上，也可能分布于多台计算机上。

Web 服务器用作应用程序服务器

.NET Web应用程序的常用部署模式是将业务和数据访问组件放在 Web 服务器上。这样就最大限度地减少了网络跃点，有助于提高性能。图 1 中显示了这种模型。.

图 1. Web 服务器用作应用程序服务器

远程应用程序层

远程应用程序层是常用的部署模式，尤其是以下 Internet 方案中的常用部署模式：Web 层在周边网络（也就是大家所知道的DMZ 和屏蔽的子网）中是独立的部分，它依靠数据包筛选防火墙与最终用户和远程应用程序层分隔开图 2 中显示了远程应用程序层。

图 2. 远程应用程序层简介

实现技术

.NET Web 应用程序通常使用以下技术来实现一个或多个逻辑服务：

安全体系结构

图 3显示了远程应用程序层模型和前面介绍的各种技术提供的那些安全服务。身份验证和授权在分布于各层中许多点分别进行。这些服务主要由 Internet 信息服务 (IIS)、ASP.NET、Enterprise Services 和 SQL Server 提供。同时，安全通信信道在各层上应用，并从客户端浏览器或设备一直延伸到数据库。信道的安全性由安全套接字层 (SSL) 或 IPSec 联合提供保障。

图 3. 安全体系结构

各层之间的安全性

表 1摘要说明前面讨论的技术所提供的身份验证、授权和安全通信功能。

身份验证

Windows 2000上的.NET Framework提供下面的身份验证选项：

ASP.NET 身份验证模式

ASP.NET身份验证模式包括 Windows、窗体、Passport和无身份验证。

更多信息

有关ASP.NET身份验证的更多详细信息，请参阅“ASP.NET 安全性”。

企业服务身份验证

企业服务身份验证的通过基础的“远程过程调用”(RPC) 传输基础结构来执行的，该基础结构使用操作系统的“安全服务提供程序接口”(SSPI)。可以使用 Kerberos 或 NTLM 身份验证对企业服务应用程序客户端进行身份验证。

可以在库应用程序或服务器应用程序中承载服务组件。库应用程序是在客户端进程内承载的，因此，它们采用客户端的标识。服务器应用程序在单独的服务器进程内运行，它们有自己的标识。有关标识的详细信息，请参阅本章内下文中的“标识和主体”一节。

传入的对服务组件的调用可以在以下级别进行身份验证：

更多信息

有关 Enterprise Services 身份验证的详细信息，请参阅“企业服务安全性”。

SQL Server 身份验证

SQL Server 既可以使用 Windows 身份验证（NTLM 或 Kerberos）对用户进行身份验证，也可以使用其内置的身份验证方案（称为 SQL 身份验证）对用户进行身份验证。共有以下两个可用选项：

更多信息

关于每种方法的优点，请参阅“数据访问安全性”。

授权

Windows 2000上 的 .NET Framework 提供了下列授权选项：

ASP.NET 授权选项

ASP.NET授权选项可供 ASP.NET Web 应用程序、Web服务和远程组件使用。 ASP.NET 提供下面的授权选项：

更多信息

有关ASP.NET授权的详细信息，请参阅“ASP.NET 安全性”。

Enterprise Services 授权

对企业服务应用程序内服务组件中所含功能的访问受企业服务角色成员身份制约。与.NET角色不同，它们可以包含 Windows 组或用户帐户。角色成员身份在 COM+ 目录内定义并通过使用“组件服务”工具管理。

更多信息

有关 Enterprise Services 授权的详细信息，请参阅“企业服务安全性”。

SQL Server 授权

SQL Server 允许设置细化的权限，这些权限可应用于单个数据库对象。可以让权限基于角色成员身份（SQL Server 提供固定的数据库角色、用户定义的角色和应用程序角色），也可以将权限授予单个的 Windows 用户或组帐户。

更多信息

有关 SQL Server 授权的详细信息，请参阅“数据访问安全性”。

网关守卫和关口

在本文档的其余部分，术语网关守卫 用来指负责关口 的技术。关口表示应用程序内的访问控制点（保护资源）。例如，资源可以是某个操作（由对象的方法表示）或数据库或文件系统资源。

前面所列的每种核心技术都为访问授权提供了网关守卫。请求必须先通过一系列的关口，然后才被允许访问所请求的资源或操作。下面说明请求必须通过的各个关口：

底线是：网关守卫根据调用到关口并尝试访问特定资源的用户或服务的标识来授权。多个关口的好处是通过多条防御线提供纵深防御安全机制。表 2.2 摘要说明各种网关守卫及其负责的关口。

通过在应用程序各层上使用各种关口，您可以筛选出应允许哪些用户访问您的后端资源。请求在通过应用程序到达后端资源的过程中，一系列相连的关口的控制越来越细化，使得访问范围逐步缩小。

请考虑使用 IIS 的基于 Internet 的应用程序示例，如图 4 所示。

图 4 用网关守卫筛选用户

图 4 说明以下几点：

返回页首

介绍 .NET Framework 安全性

.NET Framework 安全性在 Windows 安全性之上；它没有取代Windows安全性，而是提供附加的安全特性。.NET 应用程序对所有资源访问的成功或者失败最终由操作系统的安全性决定。

例如，如果一个 ASP.NET Web 应用程序要打开一个文件，能否打开文件取决于和此文件相关的Windows ACL。用于资源访问的标识要么是 ASP.NET 应用程序进程标识，要么是使用个性化处理的应用程序的个性化标识。

代码访问安全性

.NET Framework提供一个被称为代码访问安全性 (CAS) 的附加的安全性机制。传统的安全性（例如 Windows 提供的安全性）是以主体为中心的，并且授权基于一个验证的主体，例如用户运行代码，或者用户登录一个 Web 应用程序。

CAS 通过支持基于代码标识（而不是运行代码的用户）的授权为安全性添加了一项内容。这对于使用 Internet Explorer 从 Internet 上下载的移动代码（例如控件和应用程序）尤为重要。这是因为您可能以管理员的身份登录您的计算机，但是您真的想让这种代码具有管理员权限吗？如果您考虑到计算机的安全性，您可能不会允许的。

证据和安全策略

代码被验证并且其标识使用代码的属性来决定，这种代码被称作为证据。证据可以包含一个汇编的公共钥匙（是其强名称的一部分）、下载 URL、安装应用程序目录和其它内容。一旦建立了代码标志，收集的证据通过安全性策略传递，安全性策略最终管理代码的功能以及给予何种许可访问安全资源。

缺省策略确保安装到本地机器上的所有代码都是完全可信的，并且可以不受限制地访问安全资源。因此所有资源访问只受操作系统安全性管理。由于在安装软件时首先要求管理员作出谨慎的决定，所以安装到本地机器上的代码是完全可信的。

CAS 和 ASP.NET Web 应用程序

ASP.NET应用程序安装到本地 Web 服务器上，因此在服务器上缺省策略给予 Web 应用程序完全的信任。这意味着 CAS 对服务器端 Web 应用程序开发人员来说使用范围有限。实际上，建立于 .NET Framework 版本 1之上的 ASP.NET Web 应用程序必须作为完全信任的应用程序运行。

注.NET Framework 的 1.1 版本添加了对部分信任 Web 应用程序的支持，这样就可以使 CAS 有效的使用于服务器端 Web 应用程序。引入 CAS 主要的好处是易于将应用程序之间分离开，以及将应用程序和关键的系统资源分离开；这对于由不同公司开发的可以承载多个 Web 应用程序的 Internet Service Providers (ISPs) 和 Application Service Provides (ASPs) 是一个重要的考虑因素。

主体和标识

尽管 CAS 以代码为中心，但是 .NET Framework 安全性的其它方面以主体为中心。 .NET Framework 安全性以主体为中心对 ASP.NET 应用程序安全性起着支配作用。

Windows 安全性的用户中心概念基于登录会话提供的安全上下文，而 .NET 安全性基于 IPrincipal 和 IIdentity 对象。

在 Windows 编程中，如果要了解运行的代码所依赖的安全上下文，应查询进程所有者的标识或当前所执行线程的标识。在 .NET 编程中，如果要查询当前用户的安全上下文，应从 Thread.CurrentPrincipal 检索当前的 IPrincipal 对象。

运行 .NET 代码时。NET Framework 使用标识对象和主体对象来表示用户，这两个对象共同构成基于 .NET 角色的授权的主干部分。对 ASP.NET Web 应用程序来讲,通过附加到当前线程和 Web 请求的主体和标志对象来表征验证的用户。

IPrincipal 和 IIdentity 接口

标识和主体对象必须分别实现IIdentity 和 IPrincipal 接口。这些接口在 System.Security.Principal 名称空间内定义。公共接口使 .NET Framework 能以多态方式处理标识和主体对象，而不管基础实现的详细情况如何。

IPrincipal 接口使您可以通过 IsInRole 方法测试角色的成员身份，同时也提供了对关联的 IIdentity 对象的访问。

public interface IPrincipal
{
  bool IsInRole( string role );
  IIdentity Identity {get;}
}

IIdentity 接口提供有关身份验证的更多详细信息，如名称和验证类型。

public interface IIdentity
{
  string authenticationType {get;}
  bool IsAuthenticated {get;}
  string Name {get;}
}

.NET Framework 提供了 IPrincipal 和IIdentity 的多个具体实现，如图 5 所示，后面几节对这些实现分别进行详细说明。

图 5. IPrincipal 和 IIdentity 实现类

WindowsPrincipal 和 WindowsIdentity

Windows 安全上下文的 .NET 版本分为两个类：

GenericPrincipal 和 Associated Identity 对象

这些实现非常简单，供不使用 Windows 身份验证的应用程序在应用程序不需要主体的复杂表示时使用。您可以在代码中非常容易地创建这些实现，因此，在应用程序处理 GenericPrincipal 时，必须存在某种程度的信任。

如果依靠GenericPrincipal 上的 IsInRole 方法作出授权决定，必须信任向您发送GenericPrincipal的应用程序。这与使用 WindowsPrincipal 对象形成对比：使用 WindowsPrincipal 对象时，必须委托操作系统提供有效的 WindowsPrincipal 对象，和一个授权表示符以及有效的组/角色名。

以下类型的标识对象可以与 GenericPrincipal 类相关联：

ASP.NET 和HttpContext.User

通常，作出任何授权决定之前，先要在 .NET 代码中检查 Thread.CurrentPrincipal。不过，ASP.NET 使用HttpContext.User提供经过身份验证的用户的安全上下文。

该属性接受并返回 IPrincipal 接口。，该属性包含一个与当前的请求相关的经过身份验证的用户。ASP.NET 在作出授权决定时将检索 HttpContext.User 。

使用 Windows 身份验证时，Windows 身份验证模块自动构造 WindowsPrincipal 对象并将它存储在 HttpContext.User。如果使用其他身份验证机制（如窗体或 Passport），必须构造 GenericPrincipal 对象并将它存储在 HttpContext.User 中。

ASP.NET 标识

在 ASP.NET 应用程序执行过程中的任何给定时间内，单个请求中可能存在多个标识。它们包括：

更多信息

Remoting 与 Web 服务

在.NET Framework, 的最新版本中，Remoting 与 Web 服务没有自己的安全模型。它们都继承 IIS 和 ASP.NET 的安全功能。

虽然远程处理体系结构中没有内置的安全功能，但在设计时考虑到了安全性。开发人员和/或管理员可以自行决定在远程处理应用程序中集成一定程度的安全性。是否在远程处理边界之间传递主体对象取决于客户端和远程对象的位置，例如：

返回页首

小结

本章介绍了与 .NET 相关的各种技术提供的所有身份验证和授权选项。也介绍了 .NET Framework 安全性，以及主体和标识对象，这些是 ASP.NET 验证的核心内容。.

通过在整个 .NET 应用程序中使用多个网关守卫，您将能够实现纵深防御安全策略。概括起来，有以下几点：