开始
为分布式 Web 应用程序设计身份验证和授权策略是一项具有挑战性的任务。令人欣慰的是，在应用程序开发的早期阶段，正确设计身份验证和授权将有助于降低许多安全方面的主要风险。
本章将帮助您为应用程序设计合适的授权策略，还将帮助您解答下列关键问题：
| • | 应该在什么地方执行授权，使用什么机制？
|
| • | 应该使用什么身份验证机制？
|
| • | 应该用 Active Directory® 目录服务来进行身份验证验证，还是应该对照自定义数据存储来验证凭据？
|
| • | 使用异类平台和同类平台分别意味着什么？在设计上有哪些需要注意的地方？
|
| • | 在应用程序中应该如何表示不使用 Microsoft® Windows® 操作系统的用户？
|
| • | 应该如何在应用程序的各层之间传递用户标识？在什么情况应该使用操作系统级别的模拟/委派？
|
当您考虑授权时，也必须考虑身份验证。这两个过程紧密相关，其中有以下两个方面的原因：
| • | 第一，任何有意义的授权策略都需要已验证身份的用户。
|
| • | 第二，验证用户标识的方式（具体说，就是如何在应用程序中表示已经过验证的用户标识）将决定您可支配的网关守卫。
某些网关守卫（例如 ASP.NET 文件授权、企业服务 (COM+) 角色和 Windows ACL）要求经过身份验证的 Windows 标识，此类标识采用 WindowsIdentity 对象的形式，该对象封装的是用来定义调用方安全性上下文的 Windows 访问令牌。而其他网关守卫（例如 ASP.NET URL 授权和 .NET 角色）则无此要求。它们只要求标识经过验证即可，并不需要一定要用 Windows 访问令牌来表示标识。
|
设计身份验证和授权策略
您可采用下列步骤为应用程序开发身份验证和授权策略：
| 1.
| 确定资源
|
| 2.
| 选择授权策略
|
| 3.
| 选择用于获得资源访问的标识
|
| 4.
| 考虑标识传递
|
| 5.
| 选择身份验证方法
|
| 6.
| 决定如何传递标识
|
确定资源确定应用程序需要向客户端公开的资源。典型的资源包括：
| • | Web Server 资源，例如 Web 页、Web 服务、静态资源（HTML 页面和图像）。
|
| • | 数据库资源，例如每个用户的数据或应用程序范围的数据。
|
| • | 网络资源，例如远程文件系统资源和来自目录存储（如 Active Directory）的数据。
|
还必须确定您的应用程序所要访问的系统资源。这些资源与向客户端公开的资源相反，是不公开的。系统资源包括注册表、事件日志和配置文件。
选择授权策略有两种基本的授权策略：
| • | 基于角色。对操作（通常是方法）的访问权限是根据调用方的角色成员身份来提供的。使用角色将应用程序的用户群分为在应用程序内共享相同安全权限的用户组，例如“高级经理”、“经理”和“职员”。用户被映射到角色，如果用户有权执行所请求的操作，那么应用程序将使用固定标识访问资源。这些标识被各自的资源管理器（例如数据库、文件系统等）所信任。
|
| • | 基于资源。单个的资源是通过 Windows ACL 来提供保护的。应用程序在访问资源之前先模拟调用方，这使操作系统可以执行标准访问检查。对资源的所有访问都是使用原调用方的安全性上下文执行的。此模拟方法严重影响应用程序的可伸缩性，因为这意味着在应用程序的中间层无法高效地使用连接池。
|
对于绝大多数在伸缩性方面有很高要求的 .NET Web 应用程序来说，基于角色的授权方法是最佳选择。而对于某些规模较小的 Intranet 应用程序，如果它们所提供的各用户内容来自可通过对单个用户执行 Windows ACL 检查来提供访问权限的资源（例如文件），则可采用基于资源的授权方法。
在进行基于角色的授权时，所推荐使用的和常见的做法是：
| • | 在前端 Web 应用程序中验证用户标识。
|
| • | 将用户映射到角色。
|
| • | 根据角色成员身份授权对操作（而非直接对资源）的访问权限。
|
| • | 使用固定的服务标识，访问必要的后端资源（用来支持所请求的和授权的操作）。后端资源管理器（例如数据库）“信任”应用程序授权调用方，而且愿意将权限授予被信任的服务标识或其他标识。
例如，数据库管理员可以将访问权限只授予某个特定的人力资源应用程序（而不是授予单个的用户）。
|
注意：基于应用程序级别角色的授权方法仍然需要使用基于资源的授权保护系统级别的资源，例如配置文件、注册表项等等。
选择用于访问资源的标识请回答这样的问题：“谁将访问资源”？
选择在访问应用程序各个级别的资源时所应使用的标识。这些资源可以由基于 Web 的应用程序来访问，还可以由 Web 服务、企业服务和 .NET Remoting 组件来访问。一般来讲，用于访问资源的标识可以是以下几类：
| • | 原调用方标识。它采用一种模拟/委派模型，即可以获得原调用方的标识，然后将此标识在系统的每一层之间传递。委派因素是用于确定身份验证机制的一个重要标准。
|
| • | 进程标识。这是默认情况（没有具体的模拟）。使用当前进程标识访问本地资源并进行下游调用。这一方法是否可行取决于所要跨越的边界，因为进程标识必须被目标系统所识别。
这意味着要用以下方式之一来进行调用：
| • | 在同一个 Windows 安全域中
| | • | 跨 Windows 安全域（使用信任和域帐户，如果不存在信任关系，则使用重复的用户名和密码）
|
|
| • | 服务帐户。这一方法使用一个（固定的）服务帐户。例如：
| • | 如果是访问数据库，它可以是由与数据库连接的组件提供的固定 SQL 用户名和密码。
| | • | 当需要固定的 Windows 标识时，则可以使用企业服务服务器应用程序。
|
|
| • | 自定义标识。当没有可用的 Windows 帐户时，您可以构建自己的标识（使用 IPrincipal 和 IIdentity 实现），它将包含您指定的安全性上下文的具体内容。例如，它可以包含角色列表、唯一标识符或任何其他类型的自定义信息。
通过用 IPrincipal 和 IIdentity 类型实现您的自定义标识，并将 IPrincipal 和 IIdentity 类型放在当前的 Web 上下文（使用 HttpContext.User）中，您可以直接从内置网关守卫（如 .NET 角色和 PrincipalPermission 请求）中获益。
|
考虑标识传递要支持按用户进行授权、审核和按用户检索数据，您可能需要在不同的应用程序层中和在不同计算机之间传递原调用方标识。例如，如果某个后端资源管理器需针对每个调用方进行授权，则调用方的标识就必须传递给该资源管理器。
您要根据系统的资源管理器授权要求和审核要求来确定需要在应用程序中传递的标识。
选择身份验证方法影响身份验证方法选择有两个关键因素：第一，也是最重要的因素是，应用程序的用户群的特点（他们使用哪一类浏览器以及他们是否有 Windows 帐户），第二是，应用程序的模拟/委派要求和审核要求。
决定如何传递标识可以在应用程序级传递标识（以提供安全性上下文），或者在操作系统级传递标识和安全性上下文。
要在应用程序级传递标识，请使用方法和存储过程参数。应用程序标识传递支持：
SELECT x,y FROM SomeTable WHERE username="bob"
操作系统标识传递支持：
| • | 平台级审核（例如，Windows 审核和 SQL Server 审核）
|
| • | 基于 Windows 标识按用户进行授权
|
要在操作系统级传递标识，可以使用模拟/委派模型。在某些情况下，可以使用 Kerberos 委派，而在另外一些情况下（或许是环境不支持 Kerberos），可能需要使用其他方法，例如使用基本身份验证。在基本身份验证中，用户凭据可供服务器应用程序使用，而且还可以用于访问下游网络资源。
