第 3 章 –身份验证和授权

了解用来在应用程序的各层之间传递标识的各种选项。

确定要在分布式 Web 应用程序中使用的适当身份验证和授权机制。

在分布式 .NET Web 应用程序中比较和对照身份验证和授权的“模拟/委派”（又称“原始调用方”）和“受信任子系统”这两个模型。

比较和对照基于角色的授权以及基于资源的授权。

Windows XP 或 Windows 2000 Server (service pack 3) 和更高版本的操作系统

Microsoft Internet 信息服务 (IIS) 5.0 和更高版本

Microsoft Active Directory

.NET Framework 版本 1.0 (Service Pack 2) 和更高版本

SQL Server 2000 (Service Pack 2) 和更高版本

阅读第 1 章简介。其中对与分布式 Web 应用程序相关的“身份验证”和“授权”这两个术语进行了定义。

阅读第 2 章 ASP.NET 应用程序的安全模型。其中概述了在创建分布式 ASP.NET Web 应用程序的过程中所采用的体系结构和技术。它详细介绍了本章中重点讨论的身份验证和授权机制，并定义了授权主题中的两个核心概念：网关和网关守卫。

阅读下列各章，它们演示了如何实施本章所讨论的身份验证和授权技巧：

应该在什么地方执行授权，使用什么机制？

应该使用什么身份验证机制？

应该用 Active Directory® 目录服务来进行身份验证验证，还是应该对照自定义数据存储来验证凭据？

使用异类平台和同类平台分别意味着什么？在设计上有哪些需要注意的地方？

在应用程序中应该如何表示不使用 Microsoft® Windows® 操作系统的用户？

应该如何在应用程序的各层之间传递用户标识？在什么情况应该使用操作系统级别的模拟/委派？

第一，任何有意义的授权策略都需要已验证身份的用户。

第二，验证用户标识的方式（具体说，就是如何在应用程序中表示已经过验证的用户标识）将决定您可支配的网关守卫。
某些网关守卫（例如 ASP.NET 文件授权、企业服务 (COM+) 角色和 Windows ACL）要求经过身份验证的 Windows 标识，此类标识采用 WindowsIdentity 对象的形式，该对象封装的是用来定义调用方安全性上下文的 Windows 访问令牌。而其他网关守卫（例如 ASP.NET URL 授权和 .NET 角色）则无此要求。它们只要求标识经过验证即可，并不需要一定要用 Windows 访问令牌来表示标识。

Web Server 资源，例如 Web 页、Web 服务、静态资源（HTML 页面和图像）。

数据库资源，例如每个用户的数据或应用程序范围的数据。

网络资源，例如远程文件系统资源和来自目录存储（如 Active Directory）的数据。

基于角色。对操作（通常是方法）的访问权限是根据调用方的角色成员身份来提供的。使用角色将应用程序的用户群分为在应用程序内共享相同安全权限的用户组，例如“高级经理”、“经理”和“职员”。用户被映射到角色，如果用户有权执行所请求的操作，那么应用程序将使用固定标识访问资源。这些标识被各自的资源管理器（例如数据库、文件系统等）所信任。

基于资源。单个的资源是通过 Windows ACL 来提供保护的。应用程序在访问资源之前先模拟调用方，这使操作系统可以执行标准访问检查。对资源的所有访问都是使用原调用方的安全性上下文执行的。此模拟方法严重影响应用程序的可伸缩性，因为这意味着在应用程序的中间层无法高效地使用连接池。

在前端 Web 应用程序中验证用户标识。

将用户映射到角色。

根据角色成员身份授权对操作（而非直接对资源）的访问权限。

使用固定的服务标识，访问必要的后端资源（用来支持所请求的和授权的操作）。后端资源管理器（例如数据库）“信任”应用程序授权调用方，而且愿意将权限授予被信任的服务标识或其他标识。

例如，数据库管理员可以将访问权限只授予某个特定的人力资源应用程序（而不是授予单个的用户）。

有关这两种截然不同的授权方法，请参见本章后面的授权方法。

有关基于角色的授权以及各种可以使用的角色类型，请参见本章后面的基于角色授权。

原调用方标识。它采用一种模拟/委派模型，即可以获得原调用方的标识，然后将此标识在系统的每一层之间传递。委派因素是用于确定身份验证机制的一个重要标准。

进程标识。这是默认情况（没有具体的模拟）。使用当前进程标识访问本地资源并进行下游调用。这一方法是否可行取决于所要跨越的边界，因为进程标识必须被目标系统所识别。

这意味着要用以下方式之一来进行调用：

服务帐户。这一方法使用一个（固定的）服务帐户。例如：

自定义标识。当没有可用的 Windows 帐户时，您可以构建自己的标识（使用 IPrincipal 和 IIdentity 实现），它将包含您指定的安全性上下文的具体内容。例如，它可以包含角色列表、唯一标识符或任何其他类型的自定义信息。
通过用 IPrincipal 和 IIdentity 类型实现您的自定义标识，并将 IPrincipal 和 IIdentity 类型放在当前的 Web 上下文（使用 HttpContext.User）中，您可以直接从内置网关守卫（如 .NET 角色和 PrincipalPermission 请求）中获益。

使用受信任的查询参数来按用户检索数据

在任何应用程序层中自定义审核

平台级审核（例如，Windows 审核和 SQL Server 审核）

基于 Windows 标识按用户进行授权

基于角色。用户被划分为应用程序定义的逻辑角色。在应用程序中，某一特定角色的成员将共享相同的权限。对操作（通常由方法调用表示）的访问是根据调用方的角色成员身份进行授权的。
使用固定标识（例如 Web 应用程序的或 Web 服务的进程标识）访问资源。资源管理器信任应用程序可以正确授权用户，并且它们将权限授予“受信任”的标识。

基于资源。各个资源是通过 Windows ACL 得到保护的。ACL 决定了哪些用户可以访问资源，还决定每个用户可以执行哪类操作（读取、写入、删除等）。
使用原调用方标识（使用模拟）来访问资源。

第一种情况是，可以在后端资源管理器（如数据库）中映射角色。它要求将原调用方的安全性上下文通过应用程序的各层一直传递到后端数据库。

另一种情况是在前端 Web 应用程序中映射角色。如果是运用这种方法，那么就要通过固定标识来访问下游资源管理器，而这些资源管理器对这些标识进行了授权并愿意信任它们。

第三种选择是在前端层和后端层之间的某个位置进行角色映射；例如：在中间层企业服务应用程序中。

受信任的子系统模型

模拟/委派模型

对用户进行身份验证

将用户映射到角色

根据角色成员身份进行授权

使用固定的受信任标识访问下游资源管理器

创建两个 Windows 帐户，一个用于读取操作，一个用于读取/写入操作。
通常，使用不同的帐户映射特定于应用程序的角色。例如，您最好让 Internet 用户使用一个帐户，而让内部操作员和/或管理员使用另一个帐户。

将每个帐户映射到一个 SQL Server 用户定义的数据库角色，并且为每个角色建立必要的数据库权限。

将用户映射到应用程序中的角色，并在连接到数据库之前使用角色成员身份确定所要模拟的帐号。

它允许下游服务借助原调用方标识来按调用方进行授权。

它允许下游服务使用操作系统级审核功能。

技术挑战。大多数安全服务提供程序不支持委派，Kerberos 是个重要的例外。
执行模拟的进程需要更高的权限（具体说就是“作为操作系统一部分”权限）。（此限制适用于 Windows 2000，对 Windows .NET Server 并不适用）。

可伸缩性。模拟/委派模型意味着您无法高效地使用数据库连接池，因为访问数据库时所使用的连接与原调用方的不同安全性上下文密切相关。这极大限制了应用程序扩展到大量用户的能力。

更多管理工作。维护后端资源上的 ACL 时，需要授予每一个用户适当的访问级别。随着后端资源的数量增加（因此用户数量也增加）时，需要执行大量的工作来管理 ACL。

可伸缩性。受信任子系统模型支持连接池，这是应用程序可伸缩性的一项基本要求。连接池允许多个客户端重用可用的池连接。它非常适合于此模式，因为无论调用方的标识是什么，对后端资源的所有访问都将使用服务帐户的安全性上下文。

后端 ACL 管理工作减到最少。只有服务帐户访问后端资源（例如数据库）。仅针对此标识来配置 ACL。

用户无法直接访问数据。在受信任的子系统模型中，只有中间层服务帐户才有权访问后端资源。因此，如果用户不通过应用程序（并且以应用程序授权为准），就无法直接访问后端数据。

审核。要在后端执行审核，可以（在应用程序级）将原调用方标识以明文方式传递到后端，并在那里执行审核。您必须信任中间层，而且确实有潜在的拒绝风险。或者，可以在中间层生成审核记录，然后将它与后端审核记录相关联（为此，必须确保服务器时钟是同步的）。

增加了服务器攻击危险。在受信任的子系统模型中，中间层服务被授予对后端资源的广泛访问权限。因此，存在安全隐患的中间层服务可能使攻击者更容易获得对后端资源的广泛访问权限。

要在应用程序级传递标识，一般使用方法参数或存储过程参数传递凭据（或票证）。

注意：携带已通过身份验证的调用方的标识的 GenericPrincipal 对象不会在进程间自动传递。这需要自定义代码。

可以向存储过程传递允许您检索和处理特定用户数据的参数。例如：

SELECT CreditLimit From Table Where UserName="Bob"

此方法有时称为“受信任的查询参数”方法。

操作系统标识传递需要采用委派，它是模拟的一种扩展形式。

.NET 角色

企业服务 (COM+) 角色

SQL Server 用户定义的数据库角色

SQL Server 应用程序角色

有关基于 .NET 角色的授权的详细信息，请参见第 8 章 ASP.NET 安全性。

有关创建 GenericPrincipal 对象的详细信息，请参阅本指南中的如何利用窗体身份验证创建 GenericPrincipal 对象。

文件

文件夹

Web 页（.aspx 文件）

Web 服务（.asmx 文件）

对象

方法和属性

方法中的代码块

捕获用户的凭据。

对照自定义数据存储（如 SQL Server 数据库）验证用户的凭据。

检索角色列表，构建 GenericPrincipal 对象并将它与当前的 Web 请求关联。
GenericPrincipal 对象表示已验证身份的用户并用于后面的 .NET 角色检查，例如声明性 PrincipalPermission 命令和编程方式的 IPrincipal.IsInRole 检查。

手动角色检查。对于细分授权，您可以调用 IPrincipal.IsInRole 方法，以便基于调用方的角色成员身份授予对特定代码块的访问权限。当检查角色成员身份时，AND 和 OR 逻辑都可以使用。

声明性角色检查（方法入口）。您可以使用 PrincipalPermissionAttribute 类（可以简写为 PrincipalPermission）对方法进行注释，以声明方式要求调用方提供角色成员身份。这些检查只支持 OR 逻辑。例如，您可以要求调用方至少有一个特定的角色（例如，调用方必须是出纳或经理）。用声明性检查无法指定调用方必须是经理和出纳。

强制性角色检查（在方法内检查）。可以在代码中调用 PrincipalPermission.Demand 来执行细分的授权逻辑。支持 AND 和 OR 等逻辑操作。

直接检查用户名

    GenericIdentity userIdentity = new GenericIdentity("Bob");
    if (userIdentity.Name=="Bob")
    {
    }

声明性检查

    [PrincipalPermissionAttribute(SecurityAction.Demand, User="Bob")]
    public void DoPrivilegedMethod()
    {
    }

强制性检查

    PrincipalPermission permCheckUser = new PrincipalPermission(
                                                   "Bob", null);
    permCheckUser.Demand();

直接检查角色名称

    GenericIdentity userIdentity = new GenericIdentity("Bob");
    // 角色名将从自定义数据存储中检索
    string[] roles = new String[]{"Manager", "Teller"};
    GenericPrincipal userPrincipal = new GenericPrincipal(userIdentity, 
                                                          roles);
    if (userPrincipal.IsInRole("Teller"))
    {
    }

声明性检查

    [PrincipalPermissionAttribute(SecurityAction.Demand, Role="Teller")]
    void SomeTellerOnlyMethod()
    {
    }

强制性检查

    public SomeMethod()
    {
      PrincipalPermission permCheck = new PrincipalPermission(
                                                   null,"Teller");
      permCheck.Demand();
      // 只有 Teller（出纳）可以执行以下代码
      // 安全异常情况中没有生成 Teller 角色的成员
      . . .
    }

直接检查角色名称

    if (Thread.CurrentPrincipal.IsInRole("Teller") ||
        Thread.CurrentPrincipal.IsInRole("Manager"))
    {
      // 执行特权操作
    }

声明性检查

    [PrincipalPermissionAttribute(SecurityAction.Demand, Role="Teller"),
     PrincipalPermissionAttribute(SecurityAction.Demand, Role="Manager")]
    public void DoPrivilegedMethod()
    {
    ...
    }

强制性检查

    PrincipalPermission permCheckTellers = new PrincipalPermission( 
                                                       null,"Teller");
    PrincipalPermission permCheckManagers = new PrincipalPermission(
                                                       null,"Manager");
   (permCheckTellers.Union(permCheckManagers)).Demand();

直接检查角色名称

    if (Thread.CurrentPrincipal.IsInRole("Teller") &&
        Thread.CurrentPrincipal.IsInRole("Manager"))
    {
      // 执行特权操作
    }

声明性检查

不能用 .NET 角色以声明方式执行 AND 检查。将 PrincipalPermission 命令堆叠在一起使用会产生逻辑 OR。

强制性检查

    PrincipalPermission permCheckTellers = new PrincipalPermission(
                                                     null,"Teller");
    permCheckTellers.Demand();  
    PrincipalPermission permCheckManagers = new PrincipalPermission(
                                                     null, "Manager");
    permCheckManagers.Demand();

标识。仅当应用程序用户的 Windows 帐户可由受信任的机构进行身份验证，并且应用程序的 Web 服务器可以访问该机构时，才适合使用 Windows 身份验证机制。

凭据管理。Windows 身份验证的一个主要优点是它使您可以让操作系统负责凭据管理。在非 Windows 方法（如“窗体”身份验证）中，您必须仔细考虑在何处以及如何存储用户凭据。两种最常见的方法是：

有关将 SQL Server 用作凭据存储的安全注意事项的详细信息，请参见第 12 章数据访问安全性。

有关对照自定义数据存储（包括 Active Directory）使用“窗体”身份验证的详细信息，请参见第 8 章 ASP.NET 安全性。

标识传递。您需要实现模拟/委派模型并在操作系统级的各层间传递原调用方的安全性上下文吗？例如，支持审核或每用户（粒度）授权。如果需要，您需要能够模拟调用方并将它们的安全性上下文委派给下一个下游子系统，详见本章前面的传递标识一节。

浏览器类型 您的用户是否都安装了 Internet Explorer，或者您是否需要支持使用混合浏览器类型的用户群？表 3.3 阐释了哪些身份验证机制要求 Internet Explorer 浏览器，以及哪些身份验证机制支持多种常见的浏览器类型。

用户在服务器的域中或可由服务器访问的受信任域中没有 Windows 帐户。

用户没有客户端证书。

支持对照自定义数据存储（通常为 SQL Server 数据库或 Active Directory）进行身份验证。

支持基于角色授权（包括从数据存储中查找角色）。

与 Web 用户界面无缝集成。

ASP.NET 构成基础结构的大部分。与传统的 ASP 比较，需要的自定义代码相对较少。

Passport 是一个集中式解决方案。

它解决了应用程序中的凭据管理问题。

它可用于基于角色的授权方案。

非常安全，因为它建立在加密技术之上。

有关 Web 服务身份验证方法的详细信息，请参见第 10 章 Web 服务安全性。

有关在 SQL Server 中使用窗体身份验证的详细信息，请参见本指南的如何将窗体身份验证用于 SQL Server 2000。

使用受信任的子系统资源访问模型可获得数据库连接池的种种好处。

如果您的应用程序没有使用 Windows 身份验证，请使用 .NET 角色检查提供授权。对照自定义数据存储验证凭据，检索角色列表并创建 GenericPrincipal 对象。将该对象与当前 Web 请求 (HttpContext.User) 关联。

如果您的应用程序使用的是 Windows 身份验证但没有使用企业服务，则请使用 .NET 角色。请记住，对于 Windows 身份验证，.NET 角色即为 Windows 组。

如果您的应用程序使用了 Windows 身份验证和企业服务，请考虑使用企业服务 (COM+) 角色。

对于使用企业服务 (COM+) 角色的有意义的基于角色授权，原调用方标识必须传递到企业服务应用程序。如果从 ASP.NET Web 应用程序中调用企业服务应用程序，这意味着 Web 应用程序必须使用 Windows 身份验证并且配置为使用模拟。

用 PrincipalPermission 属性对方法进行注释，以声明方式要求调用方提供角色成员身份。如果调用方没有指定的角色成员身份，则不会调用方法并且会产生安全异常。

在方法代码内调用 PrincipalPermission.Demand （或使用 IPrincipal.IsInRole），以实现细分授权决策。

考虑实现自定义 IPrincipal 对象以获得额外的角色检查语义。