设计由应用程序管理的授权

- 中国WEB开发者网络 (http://www.webasp.net)
-- 技术教程 (http://www.webasp.net/article/)
--- 设计由应用程序管理的授权 (http://www.webasp.net/article/5/4096.htm)
-- 作者：未知
-- 发布日期： 2003-07-12
设计由应用程序管理的授权
2002年12月

Chris Schoon、Doug Rees、Edward Jezierski
Microsoft Corporation

摘要


本指南介绍为基于 Microsoft® .NET 的单层或多层应用程序设计和编写由应用程序管理的授权的指导原则，主要讨论常见的授权任务和方案，并提供相应的信息帮助您选择最佳方法和技术。本指南适用于体系结构设计人员和开发人员。
本指南假定读者已经了解 Windows 身份验证和授权、XML Web Service 以及 .NET Remoting 等主题的基本知识。有关设计分布式 .NET 应用程序的详细信息，请参阅 MSDN® Library 中的“Designing Applications and Services”。有关分布式应用程序安全设计的详细信息，请参阅 MSDN Library 中的 Building Secure ASP.NET Applications（英文）。有关其他的常规设计准则，请参阅 Microsoft TechNet 中的 .NET Architecture Center（英文）。

下载


单击此处下载本指南（PDF 格式）。

目录


本指南包括以下各节：

简介


本指南介绍如何在基于 .NET 的应用程序中实现授权，解释术语“授权”并讨论几种执行授权的机制。本指南还包括以下内容：
  • 标识和主体等重要概念。
  • 如何使用基于角色的安全设置来授权具有相同安全特权的一类用户。
  • 基于角色的 .NET 和 COM+ 安全设置之间的主要区别。

采用何种授权机制通常取决于验证用户身份（标识）的方法。本指南将探讨以下内容：
  • Windows 身份验证和非 Windows 身份验证之间的区别。
  • 这些身份验证机制如何影响授权。
  • 如何向远程应用程序层传递用于授权的标识信息。

在典型的企业应用程序中，需要在应用程序的不同层次执行不同类型的授权。为了帮助您识别各层的授权需要以及在不同的方案中选择合适的授权策略，本指南介绍在用户界面层、业务层和数据层中通常使用的典型授权任务。图 1 显示了企业应用程序的各个层上出现的一些重要授权问题。

图 1：在企业应用程序的各层中执行授权
.NET Framework 类库提供了多种接口和类，帮助您使用基于角色的 .NET 安全设置来执行授权。本指南介绍：
  • 几种检查用户是否属于某个特定角色的技术。
  • 如何处理授权错误。
  • 在多线程的 .NET 应用程序中出现的特殊授权问题。

定义授权框架时所做的大部分工作，都可以在多个应用程序中重复使用。本指南将对以下内容进行总结：
  • 如何定义可重复使用的授权框架。
  • 使框架的安全性和性能达到最佳的原则。
注意：本指南适用于使用 .NET Framework 功能进行由应用程序管理的授权。Microsoft Windows® Server 2003 系列操作系统中的授权管理器 API 和 Microsoft Management Console (MMC) 管理单元，为应用程序提供了具有完整的基于角色的访问控制框架。授权管理器 API 也称为 AzMan，它提供了一种简化的开发模型，用于管理灵活的分组和业务规则，并可用于存储授权策略。有关详细信息，请参阅 MSDN Library 中的 Authorization Interfaces（英文）和 Authorization Objects（英文）。

了解授权


“授权”是对通过验证的主体（用户、计算机、网络设备或程序集）是否具有执行某项操作的权限的确认。授权提供的保护只允许指定用户执行特定操作，并防止恶意行为。
本节的内容如下：
  • 授权提供的保护。
  • 基本授权。
  • .NET Framework 的授权功能。

降低安全威胁


仅有授权还不足以保证应用程序的安全，因此，本指南将简要介绍应用程序面临的几种威胁。以下是一些常见的安全威胁，这些威胁通常缩写为“STRIDE”，包括：
  • 标识欺骗 - 未授权的用户冒充应用程序的合法用户
  • 篡改数据 - 攻击者非法更改或毁坏数据
  • 可否认性 - 用户否认执行了操作的能力
  • 信息泄露 - 敏感数据被泄露给本应无权访问的人或位置
  • 拒绝服务 - 导致用户无法使用应用程序的破坏行为
  • 特权升级 - 用户非法获得过高的应用程序访问特权

您可以使用以下技术来解决 STRIDE 威胁：
  • 身份验证 - 严格的身份验证有助于减少标识欺骗。当用户登录到 Windows 或启动应用程序时，他（她）会输入“凭据”信息，如用户名和密码。Windows 使用 NTLM 或 Kerberos 等协议验证用户的凭据，并让用户登录到系统。应用程序则通常使用系统登录产品，或者以实现自定义身份验证作为授权的基础。有关身份验证的详细信息，请参阅 MSDN Library 中的 Building Secure ASP.NET Applications（英文）。
  • 授权 - 使用本指南介绍的授权技术来应对数据篡改和信息泄露的威胁。
  • 标识流 - 跨多台计算机部署的应用程序，有时需要在系统中的计算机之间传递代表通过验证的用户标识的信息。如果在第一台计算机中进行身份验证，而其他应用程序逻辑驻留在单独的计算机上，通常会用到标识流。有关标识流的详细信息，请参阅本指南后面的设计用于授权的标识流。
  • 审核 - 记录已授权的和未授权的操作，减少可否认性带来的威胁。本指南不对审核进行详细介绍。有关审核的详细信息，请参阅 MSDN Library 中的 Building Secure ASP.NET Applications（英文）。

有关 STRIDE 的详细信息，请参阅 MSDN Library 中的 Designing for Securability（英文）。
图 2 显示的模型说明了如何降低多层应用程序中的 STRIDE 安全威胁。

图 2：多层应用程序的安全模型
图 2 描述的是一种具有多个物理层的部署，但是，许多较小的应用程序是在一个物理层上完成的，这就简化了身份验证、授权和标识流。图 2 包含了以下降低安全威胁的措施：
  1. 通过带宽限制来降低拒绝服务 (DoS) 的攻击。这可以防止恶意的应用程序和用户对应用程序连续进行不受欢迎的干扰，从而避免应用程序出现问题。
  2. 使用加密来保证通信安全。
  3. 身份验证可以防止标识欺骗。
  4. 身份验证根据数据存储库来验证凭证。
  5. 应用程序层之间使用标识流（可选）。
  6. 通过审核来保证可否认性。
  7. 通过授权来应对篡改和泄露数据的威胁。

选择授权机制


您可以使用多种授权机制来控制应用程序的功能，使其按预期方式运行，不被意外或蓄意误用。这些授权机制包括以下几种：
  • 系统授权 - Windows 使用访问控制列表 (ACL) 保护资源，如文件和存储过程。ACL 指定哪些用户可以访问安全资源。
  • .NET 代码访问安全性授权 - 代码访问安全性根据代码的来源授权代码以执行操作。例如，代码访问安全性根据证据标准，确定 .NET 应用程序中可以访问其他程序集的程序集。
  • 应用程序授权 - 应用程序代码自身授权用户操作。

可以综合使用这些方法创建安全的应用程序，如图 3 所示。

图 3：选择授权机制

系统授权


“系统授权”是为操作系统控制的对象（例如打印机、文件）设置资源权限或 ACL 的过程。系统管理员负责维护这些设置。系统授权是一种非“是”即“否”的决策模式：用户要么被授权访问资源，要么不被授权访问资源。
系统授权的示例包括：
  • 基于 Microsoft ASP.NET 的应用程序授权设置，用于限制对 Web.config 文件中指定的 URL 文件或路径的访问。
  • Active Directory® 目录服务中的权限设置。
  • NTFS 文件系统访问控制项。
  • 消息排队权限。
  • 服务器产品（如 Microsoft SQL Server™）中授予的权限。这种权限可能涉及各种对象，如表或视图。

有关系统级安全和授权的详细信息，请参阅 MSDN Library 中的 Building Secure ASP.NET Applications（英文）。
系统授权可以对各种对象施加约束，而限制代码则需要采用 .NET 代码访问安全性授权。

.NET 代码访问安全性授权


.NET 公共语言运库使用代码访问安全性来限制可执行的代码。代码访问安全性根据证据向应用程序代码授予权限（称为“权限设置”）。这些证据可以包括代码的来源、发布者或其他证据，如程序集的严格名称。
权限设置使您能够控制应用程序可以执行的操作，如删除文件或访问 Internet。例如，您可以限制应用程序只使用隔离的存储单元或控制打印访问。
不管用户的身份如何，代码访问安全性只考虑证据，即使具有管理特权的用户使用应用程序，代码访问安全性权限仍旧保持不变。例如，如果代码来自 Internet，不管用户是谁，对其应用的限制（如删除文件的能力）保持不变。
代码访问安全性的应用示例包括：
  • 限制下载组件的操作权利并将其放置到隔离环境中，防止下载组件执行危险操作。隔离有助于防止欺诈代码损坏系统。
  • 为在 Web 服务器或应用程序服务器上运行的宿主代码创建隔离环境。
  • 限制组件的操作权利，防止被恶意代码误用。
注意：请使用 Caspol.exe 或 Microsoft .NET Framework 配置管理控制台配置代码访问安全性。

有关代码访问安全性的详细信息，请参阅 MSDN Library 中《.NET Framework Developer's Guide》中的 Code Access Security（英文）一文。
代码访问安全性通过检查代码权限来保证系统的安全性，但可能还需要使用应用程序授权来检查用户的权限，这取决于应用程序。

应用程序授权


大多数应用程序会根据用户与系统的交互活动实现不同的功能或安全权限。设计“应用程序授权”指根据程序中的用户角色，实施业务规则或限制用户对应用程序资源的访问。
应用程序授权的主要目的是保护功能和其他无形内容，如业务逻辑。因此，很难使用当前的系统级技术实现应用程序授权，因为这些技术需要使用有关物理资源的设置，如 ACL。例如，您想确保对员工费用申请的批准操作的安全，却没有要保护的物理资源，因此，当您设计应用程序授权时，应该着眼于高级别的操作，而不是各种资源。
当系统授权机制分类过细或不考虑应用程序的数据与状态时，应用程序授权提供了另一种系统授权方法。例如，如果 XML Web Service 的系统级安全标准仍处于开发阶段，还在不断地发展丰富，那么您可以不必等到标准形成之后再向 XML Web Service 添加安全设置或创建安全的 XML Web Service。对于目前已创建的 XML Web Service，您可以实现应用程序授权，使用安全套接字层 (SSL) 或其他组合来保护对服务的调用。
应用程序授权的示例包括：
  • 检查用户是否具有执行应用程序中特定操作（如批准费用申请）的权限。
  • 检查用户是否具有访问应用程序资源（如从数据库中检索敏感数据列）的权限。

在本指南的后面部分中，您将学习如何设计这些应用程序授权以及如何编写相关代码。

入口检查


为了防止操作被连续不断地错误执行而导致最终失败，您应该始终做到尽快地对用户的每个请求进行授权。每个授权点称为“看门人”。这种看门机制的示例包括 ASP.NET 入口中的文件和 URL 授权。在标识流向各个层次传递的过程中，可能会有若干个“看门人”。在门口进行检查可以减少在系统深层（通过入口点或门以后）必需的授权检查次数。
在系统深层执行授权检查的对象需要较少的授权失败补偿逻辑。单个组件不负责处理授权失败，不会抛出异常来通知失败的调用者。

使用角色执行授权


.NET Framework 提供了基于角色的应用程序授权能力。“角色”指共享同一安全特权的一类或一组用户。
使用角色代替特定的用户标识具有以下优势：
  • 发生变化（如添加用户、提升用户或用户调离工作）时，不需要改变应用程序。
  • 维护角色的权限比维护各个用户的权限容易。例如，处理 10 个角色比处理 120 个用户容易，而且还节省时间。
  • 一个用户可以具备多个角色，这增强了分配和测试权限的灵活性。

根据业务组织定义角色


角色可以代表用户在组织中的地位，例如：
  • Manager
  • Employee
  • ClaimApprovalDepartment

使用这种方法的一个好处是信息通常可以从存储库（例如 Active Directory）中检索出来。通常情况下，这些角色在对实际业务需求进行建模时十分有用。

与组织的变化无关


您还可以使用角色来指出用户执行的工作属于哪种操作类型。这样的角色可以将应用程序的功能链接到各个用户，例如：
  • CanApproveClaim
  • CanAccessLab
  • CanViewBenefits

第二种方法更灵活一些，因为您可以围绕应用程序的功能来设计角色，而不用过多考虑组织的结构，但维护起来可能比较困难，因为缺乏保存角色的结构。大多数情况下，需要在应用程序中综合使用这些方法。

不使用角色执行授权


有时您必须以用户是谁作为授权的基础，而不会过分关注用户在应用程序中扮演的角色。例如，您可能要实现只允许部门经理批准员工的费用申请，而要达到这种授权级别，可以将当前用户与提出申请的员工的经理进行比较。
webasp.net