第9章—EnterpriseServices安全性.doc

第 9 章 — Enterprise Services 安全性 构建安全的 ASP.NET 应用程序身份验证、授权和安全通信 J.D. Meier、Alex Mackman、Michael Dunner 和 Srinath Vasireddy Microsoft Corporation 2002 年 10 月 有关构建安全的 ASP.NET 应用程序 的起点和完整概述，请参见“登录页面”。 总结 本章解释如何保护 Enterprise Services 应用程序所包含的服务组件中的业务功能。本章介绍了如何以及何时使用 Enterprise Services (COM+) 角色进行授权，以及如何配置 RPC 身份验证和模拟，还介绍了如何从 ASP.NET Web 应用程序安全调用服务组件以及如何通过中间层服务组件标识和传递原调用方的安全性上下文。 内容 安全性体系结构 配置安全性 编程安全性 选择进程标识 访问网络资源 传送原调用方 RPC 加密 构建服务组件 DCOM 和防火墙 从 ASP.NET 调用服务组件 安全性概念 总结 .NET 组件可以使用传统的 COM+ 服务，例如分布式事务、实时激活、对象池和并发管理等。在 .NET 中，将此类服务称为 Enterprise Services。对于在 .NET Web 应用程序中运行的许多中间层 .NET 组件而言，它们是必不可少的。 要向 .NET 组件中添加服务，您必须从 EnterpriseServices.ServicedComponent 基类中派生组件类，然后使用 .NET 属性（被编译到驻留该组件的程序集中）指定正确的服务要求。 本章介绍如何构建安全的服务组件，以及如何从 ASP.NET Web 应用程序中调用这些组件。 安全性体系结构 图 9.1 显示了 Enterprise Services 应用程序所支持的身份验证、授权和安全通信功能。图 9.1 中显示的客户端应用程序是一个 ASP.NET Web 应用程序。 {Insert figure: CH09 - Enterprise Services Role-Based Security.gif} 图 9.1 基于 Enterprise Services 角色的安全体系结构 注意，身份验证和安全通信功能是由分布式 COM (DCOM) 使用的基本 RPC 传输提供的。授权功能则是由 Enterprise Services (COM+) 角色提供的。 下面概述了 Enterprise Services 安全体系结构的主要构成要素： ● Enterprise Services 应用程序使用 RPC 身份验证对调用方进行身份验证。也就是说，除非您采取了特定的步骤禁用身份验证，否则就会使用 Kerberos 或 NTLM 身份验证对调用方进行身份验证。 ● 授权功能是通过 Enterprise Services (COM+) 角色提供的，这些角色可以包含 Microsoft? Windows? 操作系统组或用户帐户。角色成员身份在 COM+ 目录内定义并利用“组件服务”工具进行管理。 注意：如果 Enterprise Services 应用程序使用模拟功能，则还可以使用受保护资源的 Windows ACL 对调用方进行授权。 ● 如果客户端（例如，ASP.NET Web 应用程序）在服务组件上调用某个方法，则在身份验证进程结束后，Enterprise Services 侦听层就会访问 COM+ 目录以确定该客户端的角色成员身份。然后，它检查该角色的成员身份是否允许授权访问当前的应用程序、组件、接口和方法。 ● 如果客户端的角色成员身份具有访问权限，则调用该方法。如果客户端不属于某个相应角色，则拒绝进行调用，并且有选择地生成一个安全事件以反映失败的访问操作。 重要信息：要在 ASP.NET Web 应用程序调用的 Enterprise Services 应用程序中实现有意义的基于角色的授权，必须在 ASP.NET Web 应用程序中使用 Windows 身份验证和模拟功能，确保将原调用方的安全性上下文传递给服务组件。 ● 要保护客户端和服务器应用程序之间 DCOM 通信链路的安全，可以使用 RPC 数据包完整性身份验证级别（提供消息完整性），也可以使用 RPC 数据包保密性身份验证级别（提供消息机密性）。 关守和关口 Enterprise Services 运行库可以充当服务组件的关守。图 9.2 显示了 Enterprise Services 应用程序中的各个关口（授权点）。可通过使用 Enterprise Services 角色来配置这些关口（必须使用相应的 Windo