授权方法
有两种基本授权方法：
| • | 基于角色。用户被划分为应用程序定义的逻辑角色。在应用程序中，某一特定角色的成员将共享相同的权限。对操作（通常由方法调用表示）的访问是根据调用方的角色成员身份进行授权的。
使用固定标识（例如 Web 应用程序的或 Web 服务的进程标识）访问资源。资源管理器信任应用程序可以正确授权用户，并且它们将权限授予“受信任”的标识。
|
| • | 基于资源。各个资源是通过 Windows ACL 得到保护的。ACL 决定了哪些用户可以访问资源，还决定每个用户可以执行哪类操作（读取、写入、删除等）。
使用原调用方标识（使用模拟）来访问资源。
|
基于角色的授权在基于角色（或操作）的安全方法中，对操作（而非后端资源）的访问是根据调用方的角色成员身份进行授予的。角色（在设计应用程序时进行分析并加以定义）被用作逻辑容器，它们将应用程序中共享同一安全权限（或功能）的用户集合在一起。用户被映射到应用程序中的角色，而角色成员身份用来控制对应用程序公开的特定操作（方法）的访问权。
在应用程序的什么位置映射角色是设计中需要考虑的一个关键因素；例如
| • | 第一种情况是，可以在后端资源管理器（如数据库）中映射角色。它要求将原调用方的安全性上下文通过应用程序的各层一直传递到后端数据库。
|
| • | 另一种情况是在前端 Web 应用程序中映射角色。如果是运用这种方法，那么就要通过固定标识来访问下游资源管理器，而这些资源管理器对这些标识进行了授权并愿意信任它们。
|
| • | 第三种选择是在前端层和后端层之间的某个位置进行角色映射；例如：在中间层企业服务应用程序中。
|
在多层 Web 应用程序中，使用受信任的标识访问后端资源管理器为应用程序的伸缩性提供了更多的机会（这得归功于连接池）。另外，使用受信任的标识减少了在操作系统级传递原调用方安全性上下文的需要，而这本来可能是不太可能（即使可能，也是很难）实现的。
基于资源的授权基于资源的授权方法依赖于 Windows ACL 和操作系统的基本访问控制机制。应用程序模拟调用方，将执行访问检查的任务留给了与特定资源管理器（文件系统、数据库等）关联的操作系统。
这种方法通常最适合于以下应用程序：您利用它们来访问可通过 Windows ACL 加以个别保护的资源（如文件资源）。FTP 应用程序或简单的数据驱动 Web 应用程序就属于这类应用程序。如果被请求资源中的数据需要从多个不同来源（如多个数据库、数据库表、外部应用程序或 Web 服务等）获取和合并，那么这种方法就显得力不从心了。
基于资源的方法还依赖于传递到应用程序后端资源管理器的原调用方的安全性上下文。这可能需要进行复杂的配置，而且会大大降低多层应用程序增加受访的能力，因为使用这种方法，您就无法在应用程序中间层有效运用集合功能（如数据库连接池）。
资源访问模型通过研究 .NET Web 应用程序（以及通常所见的分布式多层应用程序）最常用的两种资源访问安全模型，我们可以看到有两种截然不同的授权方法。这两种模型是：
这两种模型在安全性和可伸缩性方面都各有优缺点。以下各节将介绍这两种模型。
受信任的子系统模型在此模型中，中间层服务使用固定标识访问下游服务和资源。原调用方的安全性上下文不通过操作系统级的服务进行传递，但应用程序可以选择在应用程序级传递原调用方标识。它这样做可能是需要支持后端审核要求，或支持按用户访问数据和授权。
该模型之所以得此名称，是因为下游服务（或许是数据库）信任上游服务，让其授权调用方。图 3.1 显示了此模型。请特别注意信任边界。在本示例中，数据库“信任”中间层让其授权调用方，并只允许经过授权的调用方使用受信任的标识访问数据库。
图 3.1
受信任的子系统模型
在受信任的子系统模型中，资源访问步骤如下：
| • | 对用户进行身份验证
|
| • | 将用户映射到角色
|
| • | 根据角色成员身份进行授权
|
| • | 使用固定的受信任标识访问下游资源管理器
|
固定标识用于访问下游系统和资源管理器的固定标识通常由预配置的 Windows 帐户（称为服务帐户）提供。在 Microsoft SQL Server™ 资源管理器中，这意味着对 SQL Server 使用 Windows 身份验证。
另一种情况是，某些应用程序使用指定的 SQL 帐户（由连接字符串中的用户名和密码指定）访问 SQL Server。在这种情况下，必须对数据库进行配置，以使用 SQL 身份验证。
有关与 SQL Server 通信时 Windows 身份验证和 SQL 身份验证的相对优点，请参见第 12 章数据访问安全性。
使用多个受信任的标识有些资源管理器可能需要根据调用方的角色成员身份，执行更进一步细分的授权。例如，您可能有两组用户，一组应被授权执行读取/写入操作，另一组则应被授权执行只读操作。
请看下面的 SQL Server 方法：
| • | 创建两个 Windows 帐户，一个用于读取操作，一个用于读取/写入操作。
通常，使用不同的帐户映射特定于应用程序的角色。例如，您最好让 Internet 用户使用一个帐户，而让内部操作员和/或管理员使用另一个帐户。
|
| • | 将每个帐户映射到一个 SQL Server 用户定义的数据库角色，并且为每个角色建立必要的数据库权限。
|
| • | 将用户映射到应用程序中的角色，并在连接到数据库之前使用角色成员身份确定所要模拟的帐号。
|
图 3.2 中显示了这一方法。
图 3.2
使用多种标识访问数据库以支持更细分的授权
模拟/委派模型在此模型中，服务或组件（通常在逻辑业务服务层中的某个位置）在访问下一个下游服务之前模拟客户端的标识（使用操作系统级模拟）。如果下一个服务在同一台计算机上，模拟就足够了。如果下游服务位于远程计算机上，则需要使用委派。
委派的结果是，用于访问下游资源的安全性上下文是客户端的安全性上下文。使用此模型通常是由于以下几种原因：
| • | 它允许下游服务借助原调用方标识来按调用方进行授权。
|
| • | 它允许下游服务使用操作系统级审核功能。
|
这一方法的一个具体示例是，中间层企业服务组件可能会在访问数据库之前模拟调用方。将使用依赖于原调用方的安全性上下文的数据库连接访问数据库。在此模型中，数据库对每个调用方进行身份验证，并基于指派给各调用方的标识（或调用方的 Windows 组成员身份）的权限做出授权决定。图 3.3 显示了模拟/委派模型。
图 3.3
模拟/委派模型
选择资源访问模型绝大多数 Internet 应用程序和大规模的 Intranet 应用程序都使用受信任的子系统模型，其主要原因是可伸缩性。模拟模式往往用于可伸缩性不是主要问题的小规模应用程序和那些审核（由于不可否认性原因）是关键问题的应用程序。
模拟/委派模型的优点模拟/委派模型最主要的优点是审核（接近数据）。审核允许管理员跟踪试图访问特定资源的用户。通常情况下，如果审核是在资源访问的精确时间、由访问资源的同一例程产生的，则认为审核最具权威性。
模拟/委派模型为下游资源访问维护用户的安全性上下文，从而为此提供支持。这允许后端系统权威性地记录用户和所请求的访问。
模拟/委派模型的缺点与模拟/委派模型有关的缺点包括：
| • | 技术挑战。大多数安全服务提供程序不支持委派，Kerberos 是个重要的例外。
执行模拟的进程需要更高的权限（具体说就是“作为操作系统一部分”权限）。（此限制适用于 Windows 2000，对 Windows .NET Server 并不适用）。
|
| • | 可伸缩性。模拟/委派模型意味着您无法高效地使用数据库连接池，因为访问数据库时所使用的连接与原调用方的不同安全性上下文密切相关。这极大限制了应用程序扩展到大量用户的能力。
|
| • | 更多管理工作。维护后端资源上的 ACL 时，需要授予每一个用户适当的访问级别。随着后端资源的数量增加（因此用户数量也增加）时，需要执行大量的工作来管理 ACL。
|
受信任的子系统模型的优点受信任的子系统模型具有以下优点：
| • | 可伸缩性。受信任子系统模型支持连接池，这是应用程序可伸缩性的一项基本要求。连接池允许多个客户端重用可用的池连接。它非常适合于此模式，因为无论调用方的标识是什么，对后端资源的所有访问都将使用服务帐户的安全性上下文。
|
| • | 后端 ACL 管理工作减到最少。只有服务帐户访问后端资源（例如数据库）。仅针对此标识来配置 ACL。
|
| • | 用户无法直接访问数据。在受信任的子系统模型中，只有中间层服务帐户才有权访问后端资源。因此，如果用户不通过应用程序（并且以应用程序授权为准），就无法直接访问后端数据。
|
受信任的子系统模型的缺点受信任的子系统模型有几个缺点：
| • | 审核。要在后端执行审核，可以（在应用程序级）将原调用方标识以明文方式传递到后端，并在那里执行审核。您必须信任中间层，而且确实有潜在的拒绝风险。或者，可以在中间层生成审核记录，然后将它与后端审核记录相关联（为此，必须确保服务器时钟是同步的）。
|
| • | 增加了服务器攻击危险。在受信任的子系统模型中，中间层服务被授予对后端资源的广泛访问权限。因此，存在安全隐患的中间层服务可能使攻击者更容易获得对后端资源的广泛访问权限。
|
传递标识
分布式应用程序可划分为多个安全子系统。例如，前端 Web 应用程序、中间层 Web 服务、远程组件和数据库代表 4 个不同的安全子系统。每个安全子系统都执行身份验证和授权。
必须识别以下子系统：它们必须将调用方的标识（以及相关的安全性上下文）传递到下一个下游子系统，以便针对原调用方进行授权。
应用程序和操作系统标识传递对比标识传递策略包括使用操作系统的委派功能或在应用程序级传递票证和/或凭据。例如：
| • | 要在应用程序级传递标识，一般使用方法参数或存储过程参数传递凭据（或票证）。
注意：携带已通过身份验证的调用方的标识的 GenericPrincipal 对象不会在进程间自动传递。这需要自定义代码。
可以向存储过程传递允许您检索和处理特定用户数据的参数。例如：
SELECT CreditLimit From Table Where UserName="Bob"此方法有时称为“受信任的查询参数”方法。
|
| • | 操作系统标识传递需要采用委派，它是模拟的一种扩展形式。
|
模拟与委派在通常情况下，服务器应用程序中的线程使用服务器进程的安全性上下文运行。组成进程安全性上下文的属性由进程的登录会话维护，并由进程级 Windows 访问令牌公开。访问本地资源和远程资源时均将使用进程级安全性上下文（由用于运行服务器进程的 Windows 帐户决定）。
模拟为服务器应用程序配置了模拟后，模拟令牌附加到用于处理请求的线程上。模拟令牌代表已通过身份验证的调用方（或匿名用户）的安全性上下文。访问本地资源时均将使用线程模拟令牌（导致使用调用方的安全性上下文）。
委派如果服务器应用程序线程试图访问远程资源，则需要委派。具体说来，被模拟的调用方的令牌必须有网络凭据。如果没有，所有远程资源访问都将以匿名用户 (AUTHORITY\ANONYMOUS LOGON) 的身份执行。
有许多因素决定是否可以委派安全性上下文。表 3.1 显示了各种 IIS 身份验证类型，并且对于每一种类型指出了是否可以委派已通过身份验证的调用方的安全性上下文。
表 3.1：IIS 身份验证类型
| | 身份验证类型 | 能否委派 | 备注 |
| 匿名
| 视情况而定
| 如果匿名帐户（默认情况下是 IUSR_MACHINE）在 IIS 中被配置为本地帐户，则除非本地（Web 服务器）计算机和远程计算机有相同的本地帐户（具有匹配的用户名和密码），否则就不能委派它。
如果匿名帐户是域帐户，则可以委派它。
|
| 基本
| 是
| 如果对本地帐户使用“基本”身份验证，并且本地和远程计算机上的本地帐户相同，则可以委派它。域帐户也可以委派。
|
| 摘要式
| 否
|
|
| 集成 Windows
| 视情况而定
| 集成 Windows 身份验证将导致 NTLM 或 Kerberos（具体取决于客户机和服务器的操作系统版本）。
NTLM 不支持委派。
Kerberos 支持有适当配置环境的委派。
有关详细信息，请参见本指南中的如何为 Windows 2000 实现 Kerberos 委派。
|
| 客户端证书
| 视情况而定
| 如果与 IIS 证书映射一起使用，并且证书映射到一个在远程计算机重复的本地帐户或映射到域帐户，则可以委派。
它起作用是因为所映射帐户的凭据存储在本地服务器上，并且用于创建交互式登录会话（有网络凭据）。
Active Directory 证书映射不支持委派。
|
重要说明：Windows 2000 下的 Kerberos 委派不受限制。也就是说，用户或许能在多台远程计算机之间制造多个网络跃点。为消除这种潜在的安全风险，应该限制域帐户的访问范围，方法是从“域用户”组中删除此帐户，只允许使用此帐户登录到特定的计算机。
