在本节中
一个功能强大的 ASP.NET 应用程序依赖于许多元素及技术的成功的相互作用。每一个解决方案的组成部分都会提供安全性功能，这些功能被设计用来满足自身需要。然而，只是从单一的一个组成部分的角度来看待安全性是不够的。为了为整体的解决方案提供安全性，必须也要考虑各个组成部分是如何相互作用的。
本节介绍了 .NET Web 应用程序体系结构和安全性，并且提供了一个可供参考的框架，而在此系列中其它的章节会向此框架中补充其它内容。本节综述了存在于一个典型的
.NET Web 应用程序各个层面的安全性特征和服务。也介绍了 .NET Framework 安全性, 并且解释了在此框架中的哪些元素对
ASP.NET Web应用程序开发人员最为重要。
目标
本章用来：
| • |
深刻理解 .NET Web 应用程序体系结构和逻辑上以及物理上的应用程序层概念。 |
| • |
了解每个实现技术提供的哪些安全性特征可以用来构建
.NET Web 应用程序，以及它们如何一起工作。 |
| • |
理解 .NET Framework
安全性功能，并且理解哪些元素对 Web 应用程序安全性最为重要。 |
| • |
比较和对照 Web 应用程序中可以使用的授权和验证机制。 |
| • |
了解如何在 .NET Web
应用程序中使用主体和标识对象。 |
| • |
确定可在应用程序中用于实现信任边界的网关守卫和关口。 |
适用于：
本章应用于下面的产品和技术：
| • |
Microsoft_ Windows_
XP 或者 Windows 2000 Server 及其以后的的操作系统 |
| • |
Internet Information
Services (IIS) |
| • |
.NET Framework
1.0 版本及其以后的版本 |
如何使用本节
为了从本章得到更多的收获：
| • |
您必须具有 ASP.NET Web
应用程序的开发经验。这将有助于您理解在本单元中讨论的各种安全性元素在何处与您的应用程序相结合。 |
| • |
阅读“构建安全的 ASP.NET
应用程序简介”，此文强调了授权、验证以及安全通信在创建安全的、分布式的Web应用程序中的重要性。同时指出了在开发安全的Web应用程序时采用的主要原则和实践。 |
本页内容
.NET
Web 应用程序
这一部分对 .NET Web 应用程序进行了简要的介绍，并且分别从逻辑上和物理上说明其特征。还介绍了用于构建
.NET Web 应用程序的各种实现技术。
逻辑层
逻辑应用程序体系结构将任何系统都视为一组相互协作的服务，这些服务分为以下几层：
此逻辑体系结构视图的意义的价值在于将普遍存在于任何系统中的各种服务区分开来、确保了适当的分离以及促成各层之间的接口定义。这种分离可以使您在实现每个逻辑层时更为谨慎地进行体系结构和设计选择，从而构建出更易于维护的应用程序。
现将各逻辑辑层描述如下：
| • |
用户服务负责客户端与系统之间的交互，并且提供一个与核心业务逻辑相连的公共网桥，这些业务逻辑由业务服务层内的组件封装。一般说来，用户服务与交互式用户关联的情况最多。不过，它们也对其他系统发出的编程请求进行初始处理，这种情况下不涉及任何可见的用户界面。身份验证和授权的确切性质因客户端类型而异，它们通常在用户服务层内执行。 |
| • |
业务层提供系统的核心功能并封装业务逻辑。它们独立于传输信道和后端系统或数据源。这就为提升系统以支持新的、不同的信道及后端系统提供了必要的稳定性和灵活性。通常，为特定业务请求提供服务涉及到业务服务层内的许多协作组件。 |
| • |
数据服务通过一般接口提供对数据（系统边界内承载的）及其他（后端）系统的访问；通过业务服务层内的组件可以方便地使用这些接口。数据服务对多种后端系统和数据源进行了抽象，并且封装了特定的访问规则和数据格式。 |
系统内各服务类型的逻辑分类既与实现这些服务的组件的可能的物理分布相关，又相对独立于它们的物理分布。
可以在任何聚合级别上标识逻辑层，具体来说，可以对整个系统（在系统环境上下文和外部交互中）标识逻辑层，也可以对系统中所含的任何子系统标识逻辑层。记住这一点也很重要。例如，承载
Web 服务的每个远程节点由用户服务（处理传入的请求和消息）、业务服务和数据服务组成。
物理部署模型
前面所述的三个逻辑服务层并不意味着存在特定数量的物理层。所有这三种逻辑服务在物理上可能位于同一台计算机上，也可能分布于多台计算机上。
Web 服务器用作应用程序服务器
.NET Web应用程序的常用部署模式是将业务和数据访问组件放在 Web 服务器上。这样就最大限度地减少了网络跃点，有助于提高性能。图
1 中显示了这种模型。.
图 1. Web 服务器用作应用程序服务器
远程应用程序层
远程应用程序层是常用的部署模式，尤其是以下 Internet 方案中的常用部署模式：Web
层在周边网络（也就是大家所知道的DMZ 和屏蔽的子网）中是独立的部分，它依靠数据包筛选防火墙与最终用户和远程应用程序层分隔开图
2 中显示了远程应用程序层。
图 2. 远程应用程序层简介
实现技术
.NET Web 应用程序通常使用以下技术来实现一个或多个逻辑服务：
| • |
ASP.NET
ASP.NET 通常用于实现用户服务。ASP.NET 提供一种可插接式体系结构，这种体系结构可用于构建
Web 页。有关 ASP.NET 安全性，的详细信息，请参阅：“ASP.NET 安全性”。 |
| • |
企业服务
Enterprise Services 为应用程序提供基础结构级别的服务。这包括分布式事务和资源管理服务，如
.NET 组件的对象池。有关Enterprise Services 的详细信息，请参阅“企业服务安全性”。 |
| • |
Web 服务
Web 服务使用基于 SOAP 的消息交换来防火墙移动数据和在异构系统之间移动数据，以此来实现数据交换和应用程序逻辑的远程调用。有关
Web 服务的详细信息，请参阅“Web 服务安全性”。 |
| • |
.NET Remoting
.NET Remoting 提供了一种用于跨越进程和计算机边界访问分布式对象的框架。有关.NET
Remoting的详细信息，请参阅“NET Remoting 安全性”。 |
| • |
ADO.NET 和 Microsoft_
SQL Server™ 2000
ADO.NET 提供数据访问服务。 ADO.NET从一开始就是专门为分布式
Web 应用程序设计的，很适合用于与 Web 应用程序有着内在联系的分离方案。SQL Server 提供使用操作系统身份验证机制（Kerberos
或 NTLM）的集成式安全性。授权由可应用于单个数据库对象的登录和细化权限提供。有关数据访问安全性的详细讨论，请参阅“数据访问安全性”。 |
| • |
Internet 协议安全性
(IPSec)
IPSec提供点对点的传输级别加密和身份验证服务。有关 IPSec 的详细信息，请参阅“安全通信”。 |
| • |
安全套接字层 (SSL)
SSL提供点对点的安全通信信道。通过该信道传输的数据都是加密的。有关 SSL
的详细信息，请参阅“安全通信”。 |
安全体系结构
图 3显示了远程应用程序层模型和前面介绍的各种技术提供的那些安全服务。身份验证和授权在分布于各层中许多点分别进行。这些服务主要由
Internet 信息服务 (IIS)、ASP.NET、Enterprise Services 和 SQL Server 提供。同时，安全通信信道在各层上应用，并从客户端浏览器或设备一直延伸到数据库。信道的安全性由安全套接字层
(SSL) 或 IPSec 联合提供保障。
图 3. 安全体系结构
各层之间的安全性
表 1摘要说明前面讨论的技术所提供的身份验证、授权和安全通信功能。
| 表 1:安全功能 |
| IIS |
匿名
基本
摘要式
Windows 集成 (Kerberos/NTLM)
证书 |
IP/DNS 地址限制
Web 权限
NTFS 权限；所请求文件的 Windows
访问控制列表 (ACL) |
SSL |
| ASP.NET |
无（自定义）
Windows
窗体
Passport |
文件授权
URL 授权
主体权限
.NET角色 |
- |
| Web Services |
Windows
无（自定义）
消息级别身份验证 |
文件授权
URL 授权
主体权限
.NET角色 |
SSL
和消息级别加密 |
| Remoting |
Windows |
文件授权
URL 授权
主体权限
.NET角色 |
SSL
和消息级别加密 |
| Enterprise Services |
Windows |
Enterprise Services (COM+)角色
NTFS权限 |
远程过程调用
(RPC) 加密 |
| SQL Server 2000 |
Windows (Kerberos/NTLM)
SQL 身份验证 |
服务器登录
数据库登录
固定数据库角色
用户定义的角色
应用程序角色
对象权限 |
SSL |
| Windows 2000 |
Kerberos
NTLM |
Windows ACLs |
IPSec |
身份验证
Windows 2000上的.NET Framework提供下面的身份验证选项：
| • |
ASP.NET身份验证模式 |
| • |
Enterprise Services身份验证 |
| • |
SQL Server 身份验证 |
ASP.NET 身份验证模式
ASP.NET身份验证模式包括 Windows、窗体、Passport和无身份验证。
| • |
Windows 身份验证。在这种身份验证模式下，ASP.NET
依靠 IIS 对用户进行身份验证并创建 Windows 访问令牌来表示经过身份验证的标识。IIIS 提供下列身份验证机制：
| • |
基本身份验证。基本身份验证要求用户以用户名和密码的形式提供证书以证明其标识。它是基于
RFC 2617提出的 Internet 标准。http://www.faqs.org/rfcs/rfc2617.html.
Netscape Navigator 和 Microsoft Internet Explorer
都支持基本身份验证。用户证书以不加密的 Base64 编码格式从浏览器传送到 Web 服务器。由于
Web 服务器得到的用户证书是不加密的格式，因此 Web 服务器可以使用用户证书发出远程调用（例如，访问远程计算机和资源）。
注 基本身份验证只应与安全信道（通常是使用
SSL 建立的）一起使用。否则，用户名和密码很容易被网络监视软件窃取。如果使用基本身份验证，应在所有页（而不仅仅是登录页）上使用
SSL，因为在发出所有后续请求时都传递证书。有关联合使用基本身份验证和 SSL 的详细信息，详见“ASP.NET
安全性”。 |
| • |
摘要式身份验证。与
IIS 5.0 一起推出的摘要式身份验证与基本身份验证类似，但它从浏览器向 Web 服务器传送用户证书时不采用不加密的格式，而采用哈希格式。
因此，它更为安全，不过它要求使用 Internet Explorer 5.0 或更高版本的客户端以及特定的服务器配置。 |
| • |
集成的 Windows
身份验证。集成的 Windows 身份验证（Kerberos 或 NTLM，具体取决于客户端和服务器配置）使用与用户
Internet Explorer Web 浏览器的加密交换来确认用户标识。只有 Internet
Explorer 支持这种验证（Netscape Navigator 不支持）。所以，这种验证一般只能在
Intranet 方案中使用，因为您能够控制 Intranet 中所用的客户端软件。如果禁用匿名访问，或拒绝通过
Windows 文件系统权限进行匿名访问，那么这种验证只能由 Web 服务器使用。 |
| • |
证书身份验证。证书身份验证使用客户端证书明确地识别用户。客户端证书由用户的浏览器（或客户端应用程序）传递到
Web 服务器。（如果是 Web 服务，则由 Web 服务客户端通过 HttpWebRequest
对象的ClientCertificates 属性来传递证书。）Web 服务器从证书中提取用户标识。该方法依赖用户计算机上安装的客户端证书，所以它一般在
Intranet 或 Extranet 方案中使用，因为您熟悉并能控制 Intranet 和
Extranet 中的用户群。IIS 在收到客户端证书后，可以将证书映射到 Windows
帐户。 |
| • |
匿名身份验证。如果不需要对客户端进行身份验证（或者您实现自定义的身份验证方案），则可以配置
IIS 进行匿名身份验证。在这种情况下，Web 服务器创建 Windows 访问令牌来表示使用同一个匿名（或来宾）帐户的所有匿名用户。默认匿名帐户是
IUSR_MACHINENAME，其中 MACHINENAME 是在安装时为计算机指定的 NetBIOS
名称。 |
|
| • |
Passport 身份验证。在这种身份验证模式下，ASP.NET使用
Microsoft Passport 的集中式身份验证服务。ASP.NET提供方便的包装对 Microsoft
Passport 软件开发工具包 (SDK) 提供的功能进行包装，该 SDK 必须安装在 Web 服务器上。 |
| • |
窗体身份验证。此方法使用客户端重定向将没有经过身份验证的用户转发到指定的
HTML 窗体，用户可以在该窗体中输入证书（通常是用户名和密码）。然后，系统对这些证书进行验证，生成身份验证票并将其返回客户端。身份验证票上有用户标识，您还可以选择在身份验证票上列出用户在会话期间所属的角色。
有时，窗体身份验证仅用于 Web 站点的个性化处理。在这种情况下，您几乎不用编写任何自定义代码，因为
ASP.NET用简单的配置自动处理这一过程的大部分工作。在个性化处理方案中，cookie 只需要保留用户名。
注：窗体身份验证以明文形式向 Web 服务器发送用户名和密码。因此，应该将窗体身份验证与
SSL 保护的信道结合使用。为了对后续请求中传输的身份验证 cookie 不间断地提供保护，您应该考虑在应用程序内的所有页上使用
SSL，而不仅仅是在登录页上使用 SSL。 |
| • |
无“无”表示不希望对用户进行身份验证，或者使用的是自定义的身份验证协议。 |
更多信息
有关ASP.NET身份验证的更多详细信息，请参阅“ASP.NET 安全性”。
企业服务身份验证
企业服务身份验证的通过基础的“远程过程调用”(RPC) 传输基础结构来执行的，该基础结构使用操作系统的“安全服务提供程序接口”(SSPI)。可以使用
Kerberos 或 NTLM 身份验证对企业服务应用程序客户端进行身份验证。
可以在库应用程序或服务器应用程序中承载服务组件。库应用程序是在客户端进程内承载的，因此，它们采用客户端的标识。服务器应用程序在单独的服务器进程内运行，它们有自己的标识。有关标识的详细信息，请参阅本章内下文中的“标识和主体”一节。
传入的对服务组件的调用可以在以下级别进行身份验证：
| • |
默认：使用安全包的默认身份验证级别。 |
| • |
无：不执行身份验证。 |
| • |
连接：仅在连接时进行身份验证。 |
| • |
调用：每次开始远程过程调用时进行身份验证。 |
| • |
数据包：鉴定并验证是否已收到所有调用数据。 |
| • |
数据包完整性：验证数据在传输过程中是否被修改过。 |
| • |
数据包保密性：验证并加密数据包，包括数据和发送者的标识及签名。 |
更多信息
有关 Enterprise Services 身份验证的详细信息，请参阅“企业服务安全性”。
SQL Server 身份验证
SQL Server 既可以使用 Windows 身份验证（NTLM 或 Kerberos）对用户进行身份验证，也可以使用其内置的身份验证方案（称为
SQL 身份验证）对用户进行身份验证。共有以下两个可用选项：
| • |
SQL Server 和 Windows.客户端可以使用
SQL Server 身份验证或 Windows 身份验证连接到 Microsoft SQL Server
的实例。有时，这也称为混合模式的身份验证。 |
| • |
仅使用 Windows。用户必须使用
Windows 身份验证连接到 Microsoft SQL Server 的实例。 |
更多信息
关于每种方法的优点，请参阅“数据访问安全性”。
授权
Windows 2000上 的 .NET Framework 提供了下列授权选项：
| • |
ASP.NET 授权选项 |
| • |
Enterprise Services
授权 |
| • |
SQL Server 授权 |
ASP.NET 授权选项
ASP.NET授权选项可供 ASP.NET Web 应用程序、Web服务和远程组件使用。
ASP.NET 提供下面的授权选项：
| • |
URL 授权.这是通过计算机配置文件和应用程序配置文件中的设置来配置的授权机制。
URL 授权使您可以限制对应用程序的“统一资源标识符”(URI) 名称空间中的特定文件和文件夹的访问。例如，您可以选择拒绝或允许指定的用户对特定文件或文件夹（通过
URL 寻址）的访问。您还可以根据用户的角色成员身份和用于发出请求（GET、POST 等等）的 HTTP 谓词类型来限制访问。
URL 授权需要经过身份验证的标识。它可以通过 Windows 或基于身份验证票的身份验证方案来获得。 |
| • |
文件授权.只有在使用
IIS 提供的一种 Windows 身份验证机制对调用方进行身份验证并且ASP.NET已配置为使用 Windows
身份验证时，文件授权才适用。
您可以使用它限制对 Web 服务器上的指定文件的访问。访问权限由与文件相关的
Windows ACL 确定。 |
| • |
主体权限需求.主体权限需求可以作为一种（以声明方式或编程方式）更加细化的访问控制机制来使用。这种权限需求使您可以根据单个用户的标识和组成员身份控制对类、方法或单个代码块的访问。 |
| • |
.NET 角色..NET角色用于将应用程序内具有相同权限的用户集合在一起。它们在概念上与以前基于角色的实现手段（例如，Windows
组和 COM+ 角色）类似。不过，与这些方法不同，.NET 角色不需要经过身份验证的 Windows 标识，可在基于身份验证票的身份验证方案（如窗体身份验证）中使用。
.NET 角色可用于控制对资源和操作的访问，并且，这类角色既可以用声明方式配置，也可以用编程方式配置。 |
更多信息
有关ASP.NET授权的详细信息，请参阅“ASP.NET 安全性”。
Enterprise Services 授权
对企业服务应用程序内服务组件中所含功能的访问受企业服务角色成员身份制约。与.NET角色不同，它们可以包含
Windows 组或用户帐户。角色成员身份在 COM+ 目录内定义并通过使用“组件服务”工具管理。
更多信息
有关 Enterprise Services 授权的详细信息，请参阅“企业服务安全性”。
SQL Server 授权
SQL Server 允许设置细化的权限，这些权限可应用于单个数据库对象。可以让权限基于角色成员身份（SQL
Server 提供固定的数据库角色、用户定义的角色和应用程序角色），也可以将权限授予单个的 Windows 用户或组帐户。
更多信息
有关 SQL Server 授权的详细信息，请参阅“数据访问安全性”。
网关守卫和关口
在本文档的其余部分，术语网关守卫 用来指负责关口 的技术。关口表示应用程序内的访问控制点（保护资源）。例如，资源可以是某个操作（由对象的方法表示）或数据库或文件系统资源。
前面所列的每种核心技术都为访问授权提供了网关守卫。请求必须先通过一系列的关口，然后才被允许访问所请求的资源或操作。下面说明请求必须通过的各个关口：
| • |
IIS 在您对用户进行身份验证（即您禁用匿名身份验证）时提供关口。
IIS Web 权限可用作访问控制机制，该机制限制 Web 用户对特定文件和文件夹的访问能力。与 NTFS
文件权限不同，Web 权限应用于所有 Web 用户，而不是单个的用户或组。 NTFS 文件权限对 Web 资源（如
Web 页、图像文件，等等）提供进一步的限制。这些限制适用于单个的用户或组。
IIS 检查 Web 权限，接着检查 NTFS 文件权限。用户必须获得两种机制的授权后才能访问文件或文件夹。如果
Web 权限检查失败，IIS 将返回HTTP 403 — 访问拒绝响应，如果 NTFS 权限检查失败，IIS
将返回HTTP 401 — 拒绝访问。 |
| • |
ASP.NET 提供了各种可配置的编程关口。其中包括
URL 授权、文件授权、主体权限需求和 .NET 角色。 |
| • |
Enterprise Services
网关守卫使用 Enterprise Services 角色来授予对业务功能的访问权限。 |
| • |
SQL Server 2000 包括一系列关口，包括服务器登录、数据库登录和数据库对象权限。 |
| • |
Windows 2000 使用与安全资源相关的
ACL 提供关口。 |
底线是：网关守卫根据调用到关口并尝试访问特定资源的用户或服务的标识来授权。多个关口的好处是通过多条防御线提供纵深防御安全机制。表
2.2 摘要说明各种网关守卫及其负责的关口。
| 表 2. 网关守卫的责任及其提供的关口 |
| Windows 操作系统 |
登录权限（肯定和否定，例如“拒绝本地登录”）
其他权限（例如“充当操作系统的一部分”）
对保护的资源（如注册表和文件系统）进行访问检查。访问检查使用与安全资源相关的ACL，这些ACL指定允许谁访问资源和不允许谁访问资源，并指定允许执行的操作类型。
TCP/IP 筛选
IP安全性 |
| IIS |
身份验证（匿名、基本、摘要式、集成、证书）
IP 地址和域名限制（它们可用来加强安全防御，但不应依靠它们，因为使用欺骗性的
IP 地址是比较容易的事情）。
Web 权限
NTFS 权限 |
| ASP.NET |
URL授权
文件授权
主体权限需求
.NET角色 |
| 企业服务 |
Windows
(NTLM / Kerberos) 身份验证
Enterprise Services (COM+)角色
模拟级别 |
| Web 服务 |
使用
IIS 和ASP.NET提供的关口 |
| 远程处理 |
使用主机提供的关口。如果是在
ASP.NET中承载的，它使用 IIS 和 ASP.NET 提供的关口。如果是在 Windows 服务中承载的，则必须开发自定义的解决方案
。 |
| ADO.NET |
连接字符串可以使用显式证书，也可以使用
Windows 身份验证（例如，连接到 SQL Server 时） |
| SQL Server |
服务器登录
数据库登录
数据库对象权限 |
通过在应用程序各层上使用各种关口，您可以筛选出应允许哪些用户访问您的后端资源。请求在通过应用程序到达后端资源的过程中，一系列相连的关口的控制越来越细化，使得访问范围逐步缩小。
请考虑使用 IIS 的基于 Internet 的应用程序示例，如图 4 所示。
图 4 用网关守卫筛选用户
图 4 说明以下几点：
| • |
您可以在 IIS 中禁用匿名身份验证。这样，将只允许经过
IIS 身份验证的帐户进行访问。这可将潜在用户数减到 10,000。 |
| • |
接着，您可以在 ASP.NET中使用
URL 授权，这可将用户数减到 1,000。 |
| • |
文件授权可能会将访问范围进一步缩小，将用户数减少到
100。 |
| • |
最后，根据特定的角色成员身份，Web
应用程序代码可能只允许 10 个用户访问受限制的资源。 |
介绍
.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 版本分为两个类：
| • |
WindowsPrincipal.该类存储与当前的
Windows 用户相关的角色。WindowsPrincipal实现将 Windows 组视为角色。IPrncipal.IsInRole方法根据用户的
Windows 组成员身份返回 true 或 false。 |
| • |
WindowsIdentity该类存储当前用户安全上下文的标识部分，它可以从静态的
WindowsIdentity.GetCurrent() 方法获得。它返回具有 Token 属性的
WindowsIdentity 对象，该属性将一个表示 Windows 句柄的 IntPtr
返回给与当前执行线程关联的访问令牌。该令牌接着可被传递到本机 Win32® 应用程序编程接口 (API)
函数，如 GetTokenInformation、SetTokenInformation
和 CheckTokenMembership 等等，用于检索与令牌有关的安全信息。
注：静态 WindowsIdentity.GetCurrent()
方法返回当前所执行线程的标识，它可能是（也可能不是）模拟的。这与 Win32 GetUserName
API类似。 |
GenericPrincipal 和 Associated Identity 对象
这些实现非常简单，供不使用 Windows 身份验证的应用程序在应用程序不需要主体的复杂表示时使用。您可以在代码中非常容易地创建这些实现，因此，在应用程序处理
GenericPrincipal 时，必须存在某种程度的信任。
如果依靠GenericPrincipal 上的 IsInRole
方法作出授权决定，必须信任向您发送GenericPrincipal的应用程序。这与使用 WindowsPrincipal
对象形成对比：使用 WindowsPrincipal 对象时，必须委托操作系统提供有效的 WindowsPrincipal
对象，和一个授权表示符以及有效的组/角色名。
以下类型的标识对象可以与 GenericPrincipal 类相关联：
| • |
FormsIdentity该类表示已经过窗体身份验证的标识。它包含的
FormsAuthenticationTicket 中存储了与用户的身份验证会话有关的信息。 |
| • |
PassportIdentity该类表示已经过
Passport 身份验证的标识，它包含 Passport 配置文件信息。 |
| • |
GenericIdentity该类表示一个不与任何特定操作系统技术相关的逻辑用户，通常用在自定义的身份验证和授权机制中。 |
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 应用程序执行过程中的任何给定时间内，单个请求中可能存在多个标识。它们包括：
| • |
HttpContext.User返回IPrincipal对象，该对象包含当前
Web 请求的安全信息。这是经过身份验证的 Web 客户端。 |
| • |
WindowsIdentity.GetCurrent()返回当前所执行的
Win32 线程的安全上下文标识。默认情况下，该标识为 ASPNET；这是用于运行 ASP.NET Web
应用程序的默认帐户。.但是，如果已配置 Web 应用程序进行模拟，该标识则表示经过身份验证的用户（如果 IIS
匿名身份验证有效，该标识为 IUSR_MACHINE）。 |
| • |
Thread.CurrentPrincipal返回当前所执行的
.NET 线程（它位于 Win32 线程之上）的主体。 |
更多信息
| • |
有关 Web 应用程序配置组合（包括使用模拟和不使用模拟）的ASP.NET标识的详细分析，请参阅“ASP.NET
Identity Matrix”。 |
| • |
有关创建您自己的IPrincipal实现的详细信息，请参阅“ASP.NET
安全性”和“How to implement IPrincipal”。 |
Remoting 与 Web 服务
在.NET Framework, 的最新版本中，Remoting 与 Web 服务没有自己的安全模型。它们都继承
IIS 和 ASP.NET 的安全功能。
虽然远程处理体系结构中没有内置的安全功能，但在设计时考虑到了安全性。开发人员和/或管理员可以自行决定在远程处理应用程序中集成一定程度的安全性。是否在远程处理边界之间传递主体对象取决于客户端和远程对象的位置，例如：
| • |
同一进程内的远程处理。在同一应用程序域或不同的应用程序域内的对象之间使用远程处理时，远程处理基础结构将与调用方上下文相关的
IPrincipal 对象的引用复制到接收方的上下文中。 |
| • |
进程之间的远程处理。在这种情况下，不在进程之间传送
IPrincipal 对象。用于构造原始 IPrincipal 的证书必须传送到远程进程，该进程可能位于另一台计算机上。这就使得远程计算机能够根据提供的证书来构造相应的
IPrincipal 对象。 |
小结
本章介绍了与 .NET 相关的各种技术提供的所有身份验证和授权选项。也介绍了 .NET Framework
安全性，以及主体和标识对象，这些是 ASP.NET 验证的核心内容。.
通过在整个 .NET 应用程序中使用多个网关守卫，您将能够实现纵深防御安全策略。概括起来，有以下几点：
| • |
ASP.NET 应用程序可以使用
Windows 和 IIS 提供的现有安全功能。 |
| • |
SSL 和 IPSec 可用来在
.NET 应用程序的各层上（例如，从浏览器到数据库）联合提供安全通信。 |
| • |
使用基本或窗体身份验证时，可使用
SSL 保护通过网络传递的明文证书。 |
| • |
建立在 .NET Framework
版本1之上的 ASP.NET 应用程序必须作为完全可信的应用程序运行，这意味着代码访问安全性对服务器端Web应用程序开发人员来说使用范围有限。.NET
Framework 1.1 版本将提供部分信任的 Web 应用程序，在此 CAS 变得更为重要。 |
| • |
.NET 使用WindowsPrincipal
和 WindowsIdentity 类的组合来表示已经过 Windows 身份验证的用户。 |
| • |
GenericPrincipal
和 GenericIdentity 或 FormsIdentity 类用于表示已由非
Windows 身份验证方案（如窗体身份验证）验证过的用户。 |
| • |
您可以通过创建实现 IPrincipal
和 IIdentity 的类来创建自己的主体和标识实现。 |
| • |
在ASP.NET应用程序内，表示经过身份验证的用户的
IPrincipal 对象使用 HttpContext.User 属性与当前的
HTTP Web 请求关联。 |
| • |
关口是应用程序内的访问控制点，获得授权的用户可以通过这些访问控制点访问资源或服务。网关守卫负责控制对关口的访问。 |
| • |
使用多个网关守卫可以提供纵深防御安全策略。 |
| • |
Web 服务和依靠 ASP.NET
及 IIS 提供底层安全性服务的.NET remoting。 |
下一章，“身份验证和授权设计”，将提供其他一些信息来帮助您为特定应用程序方案选择最适合的身份验证和授权策略。
转到原英文页面
|
