访问管理

身份验证 在“微软身份和访问管理平台”中，建议使用 Microsoft? Active Directory? 目录服务技术来存储身份信息的技术，其中包括在身份验证流程中验证用户凭证的加密密钥。 与 Microsoft Windows Server? 2003、Microsoft Windows? XP Professional 及 Windows 安全服务相集成的应用程序通常使用操作系统的内置功能来执行身份验证。 Windows 身份验证服务 按应用程序实施身份验证协议不仅效率非常低下，而且还可能会给组织带来安全漏洞。较为合理的方法是使用 Windows 平台中的身份验证机制来构建应用程序。 为达到最佳效果，在开始应用程序设计流程前，开发人员需要了解使用不同协议及协议支持接口的不同身份验证类型和分支。 Windows 身份验证服务体系结构 Windows Server 2003 和 Microsoft Windows XP 实现了一套完整的身份验证方法和安全协议，可以满足许多应用程序的身份验证需求。Microsoft .NET Passport、通过证书或智能卡进行的公钥身份验证及用户名/密码组合因各自不同的凭证要求提供不同的用户体验，而且各种方法都各有其不同的安全特征。数据传输机制还可以定义您可以使用的身份验证协议。 “微软身份和访问管理”平台中身份验证服务的安全系统可分为划分几种级别：其范围从提供较高灵活性和控制能力的较低级别接口直到灵活性较低但应用程序编程接口 (API) 更为简单的高级别接口。下图显示了如何划分身份验证协议和应用程序 API 的层次结构。 图 6.1.Windows 操作系统中的身份验证 API 和协议层次结构 查看大图 在上图中身份验证堆栈的顶部，高级别 API 和服务提供了进程间通信 (IPC) 机制，为传输应用程序数据提供通过验证的安全通道。这种服务和 API 的示例包括分布式组件对象模型 (DCOM)、远程过程调用 (RPC)、Microsoft ASP.NET、ASP、WinInet 等等。 微软的 RPC 是一种功能强大、高效而又安全的 IPC 机制，它支持数据交换和调用驻留于不同进程中的功能。这种进程可以位于同一台计算机上，也可以位于局域网上或 Internet 中。 WinInet 是专为支持 Internet 安全协议（例如 Internet 协议上的安全套接字层 (SSL)）而设计的一种应用程序协议接口。WinInet 安全支持的实现将安全支持提供程序接口 (SSPI) 应用于安全通道（SSL 的 Windows NT? 实现）安全提供程序。 有些情况下，这些服务所公开的 API 可以帮助应用程序开发人员全面控制身份验证的执行和数据的保护。例如，DCOM API 允许开发人员选择特定的身份验证协议，如 Kerberos 协议或 NT LAN Manager (NTLM) 挑战/响应。它还指定应将数据签名（防止攻击者更改数据）还是加密（防止窃取者查看数据）。而其他服务和 API 只受系统配置的影响。最能说明这一点的是 ASP.NET，它寄宿在运行 Microsoft Internet Information Services (IIS) 6.0 的服务器上，而后者可配置为针对特定情况使用相应的身份验证机制。 安全支持提供程序接口 SSPI 是最低级别的身份验证应用程序接口，是通用安全服务 API (GSS-API) 的微软版本。有关 GSS-API 的更多信息，请参见“Internet 工程工作组”(ITEF) 请求注解 网站上的 RFC 1508 和 1509。 有关 SSPI 的更多信息，请参见 MSDN 网站上的再谈安全支持提供程序接口 一文。 SSPI 和 GSS-API 所暗含的理念是双方的网络身份验证通常遵循一种公共模式。各方需要按一定的顺序交换一条或多条信息。由于他们可以从众多不同网络协议（超文本传输协议 (HTTP)、RPC、服务器消息块 (SMB)、Internet Inter-ORB 协议 (IIOP)、DCOM、Java 远程方法调用 (RMI) 等）中选择一种进行通信，因此最好不要将单一的身份验证握手硬编码到网络协议之中。更好的办法是只提供产生“身份验证令牌”的泛型接口，这些验证令牌其实只是代表身份验证序列某个方面的二进制数据结构。这些令牌通过所用的应用程序协议进行交换。 例如，在 RPC 中，已使用握手进程来同步客户端和服务器之间的协议。RPC 只在此握手进程中为任意大小的不透明身份验证令牌提供空间。SSPI 和 GSS-API 所执行的大部分工作是生成和评估这些令牌。 如前所述，Windows Server 和客户端操作系统实现了多种身份验证协议。这些协议即是“安全数据包”，其中包括由本地安全授权服务加载的 DLL 文件。SSPI 是 Windows Server 和客户端操作系统中所有安全数据包的接口。这些安全数据包通常用于实现一项网络身份验证协议，如 Kerberos 版本5 身份验证协议、NTLM 挑战/响应、摘要身份验证、安全套接字层 (SSL) 或传输层安全 (TLS)。应用程序可以使用这些协议安全、无缝地集成 Active Directory ，进行身份验证，还可以使用协议的各种功能来保证应用程序数据的安全。 安全协议协商 (SPNEGO) 是根据需要在身份验证协议之间进行协商的特殊安全数据包。对于使用 SSPI 和 Kerberos 版本5 协议或 NTLM 的应用程序而言，最好使用 SPNEGO 数据包，而不要直接使用这些协议。有关 SPNEGO 的更多信息，请参见 MSDN 上的 Windows 安全性 页面。 Kerberos 身份验证 Kerberos 版本5 身份验证协议的说明请参见“请求注解”网站上的 IETF RFC 1510 页面。此协议具有极高的安全性和可伸缩性，因此非常适合集成网络环境中的身份验证。 在运行 Microsoft Windows 2000 Server 或其更高版本的 Windows 服务器和客户端中，Kerberos 版本5 身份验证协议是 Active Directory 身份验证的基础。它还集成在 SMB、HTTP 和 RPC 及使用这些协议的客户端和服务器应用程序中。Windows 平台为用户提供了对此强大安全工具的无缝集成体验。 Kerberos 版本5 协议对于“微软身份和访问管理”平台非常重要，因为它基于一个开放的标准。许多其他供应商业已根据 Kerberos 版本5 协议的麻省理工学院 (MIT) 实现实施了该项协议，从而为在微软和非微软平台及应用程序之间实现身份验证互操作性奠定了基础。 Windows 支持两种配置 Kerberos 版本5 协议实现互操作性的方法： ? 在 Windows 域和基于 MIT 的 Kerberos 版本5 协议领域之间建立信任关系。这种关系使得此领域中的客户端可以通过信任机制验证连接到 Windows 域中的网络资源。 ? 非 Windows 客户端和服务器可以使用 Active Directory 帐户从域控制器获得身份验证。 在 Intranet 中，在 Windows 平台上的 Kerberos 版本5 协议实现可以为用户提供 SSO 功能，这是由于身份验证协议的基本特征和协议在 Windows 客户端及服务器操作系统中实现方式的具体特性而决定的。 阻碍 Kerberos 版本5 协议成为应用程序身份验证和安全的通用解决方案的一个最主要限制是，无法将 Kerberos 身份验证配置在 Internet 上使用。其中的原因将在本章稍后的“Web 单一登录”部分详细探讨。 有关 Kerberos 版本5 身份验证协议的更多信息，请参见 Microsoft TechNet 上的循序渐进指南：Kerberos 5 (krb5 1.0) 互操作性 页面。 安全套接字层 3.0 和传输层安全 1.0 SSL 3.0 和 TLS 1.0 是两个密切相关的协议，可用于解决两应用程序间通信通道的一般安全问题。SSL 3.0 是一个专有的 Netscape 通信协议，而 TLS 1.0 是“请求注解”网站上的 IETF 标准 RFC 2246 定义。两个协议颇为相似，但 TLS 包含一些重要的改进，因此微软建议尽可能使用此协议。TLS 和 SSL 均支持在建立安全数据通道期间进行服务器身份验证，也允许选择进行客户端身份验证。 SSL 和 TLS 协议常用于在 HTTP 协议上提供数据保护和完整性（加密）。其他协议也支持 SSL 或 TLS。例如，轻型目录访问协议 (LDAP) 与 SSL 合并后产生了 LDAP over SSL，即 LDAPS。此外，自定义或第三方应用程序也可以通过 SSPI 直接使用 SSL 或 TLS，和指定 SChannel 安全数据包。 SSL 和 TLS 采用对称加密密钥提供了基于证书和安全数据传输的身份验证。在 Internet 上，组织通常使用 SSL 和 TLS 进行服务器身份验证。客户端通过核对下列条件来用 SSL 和 TLS 验证服务器： ? 服务器证书有效。 ? 经证实，服务器拥有与服务器 X.509 证书相关的相应私钥。 ? 所验证的服务器即为证书中所指定的服务器。 SSL 和 TLS 还支持客户端身份验证，并通过 X.509 客户端证书将客户端身份验证与 Windows Server 2003 平台相集成。同时进行客户端和服务器身份验证通常称为相互身份验证。为了完成客户端身份验证，客户端须提供有效的客户端证书，服务器根据针对服务器身份验证描述的条件进行衡量。Windows Server 确认客户端证书有效后，将其映射到 Active Directory 帐户。对于证书的映射方式， Active Directory 提供了很大的灵活性，既允许一对一映射，也允许多对一映射。 在使用 X.509 数字证书进行身份验证时，SSL 和 TLS 比其他身份验证协议具有更高的安全性。 注意   SSL 和 TLS 在 Windows XP 客户端上通过 Windows 凭证管理器为用户提供 Web SSO 功能，这一点将在本章稍后部分介绍。 Passport 身份验证 Microsoft Passport 是一种 Web 服务，它根据庞大的数字身份数据库对用户进行验证。个人可通过某个安全网站来维护其 Passport 身份。Passport 在许多网站启用了身份验证和 Web SSO 功能，而且在许多微软网站和一些不属于微软的站点都在使用 Passport。 开发人员可以创建链接到 Passport 的应用程序，从而使应用程序仅接受来自已注册 Passport 用户的连接。如果 Passport 确定用户的凭证有效，即会返回一个身份验证票证，应用程序可以通过解密此票证来确定用户的身份。为保护隐私，典型的 Passport 身份验证只将一个 Passport 唯一 ID (PUID) 传送给相关的应用程序。 通常，应用程序随后会将此 PUID 映射至本地维护的用户帐户，以派生在组织中有效的数字身份。在选中 IIS 6.0 中 Passport 身份验证配置选项时，Windows Server 2003 将与 Passport 完全集成。此外，还可以将 Passport 用户映射到 Active Directory 帐户，使 Passport 身份验证与 Windows 安全模型完全集成。 对于面向 Internet 的应用程序，Passport 身份验证为用户提供了 SSO 体验。Passport 通过提供在 HTTP cookie 中编码的身份验证票证来实现此项功能。引入 Cookie（在浏览器会话的生命周期内维护）后，用户无需重复登录到 Passport 身份验证服务即可完成对多个应用程序的身份验证。 有关 Passport 的更多信息，请参见 MSDN 上的.NET Passport 服务指南套件 。 摘要身份验证 摘要身份验证是“请求注解”网站上 RFC 2617 中介绍的另一种基于标准的身份验证协议，它作为一个验证数据包而包含在 Windows Server 2003 之中。摘要身份验证主要用于在 Windows 和非 Windows 平台之间实现 Internet 身份验证的互操作性。 Windows Server 2003 还将摘要身份验证作为一个简单的身份验证和安全层 (SASL) 机制来实现（如“请求注解”网站的 RFC 2831 中所述）。SASL 是应用程序和底层协议之间的另一个抽象层，通过该抽象层可以在不更改应用程序的情况下轻松引入不同的身份验证机制。在某些方面，它与先前所述的 SPNEGO 机制类似。SASL 主要用于 LDAP 身份验证。 摘要身份验证与 NTLM 专有协议具有相似的安全特征。摘要身份验证与 NTLM 均为挑战/响应协议，都需要验证服务器生成包含一些不可预知数据的挑战。随后，客户端使用从用户密码派生的密钥加密挑战，从而形成响应。服务器或者受信任的第三方服务（如 Active Directory ）通过将客户端的响应与根据身份存储中用户的相关凭证计算出的值进行比较，检验用户是否拥有正确的密码。如果响应与计算值相匹配，则认为用户知道安全密码，并通过身份验证。 一般而言，摘要身份验证不如 Kerberos 版本5 协议安全，因为它依靠强密码来防止针对挑战/响应机制的攻击。但是，由于在身份验证期间不会向服务器提供明文密码，因此摘要身份验证要比基于表单的身份验证或基本身份验证更为可靠。SSL 和 TLS 通常用于保护摘要身份验证免遭攻击。 大多数情况下，摘要身份验证的可伸缩性不如 Kerberos 版本5 协议，但它可以在无法应用 Kerberos 协议的场合使用。例如对面向外部的网站的验证。 摘要身份验证提供 SSO 只是为了保护通过单一 Web URL 得到的信息。如果用户导航至不同站点，或者导航至同一站点中的不同服务器，通常必须要再次输入他们的凭证。 基于表单的身份验证 基于表单的身份验证依靠网页中的登录表单来收集用户凭证，形式基本只有明文用户名与密码一种。因此，此类身份验证与我们前面介绍的 Kerberos 版本5 协议或摘要身份验证不同，并不是客户端和服务器之间的身份验证协议。 基于表单的身份验证需要格外小心，才能有力地保护支持它的应用程序，因此微软建议在没有 SSL 的情况下不要使用这种身份验证方式。在使用基于表单身份验证的应用程序中存在着一个很大的漏洞，攻击者可以利用它来窃取明文密码数据，这将严重危及组织中应用程序数据和网络自身的安全。 因为执行基于表单身份验证的应用程序以明文形式接收用户凭证，所以应用程序可以选择根据其他用户存储而不是 Active Directory 进行身份验证。微软建议在大多数情形下都不要使用这种方法，因为附加的身份存储会使身份和访问管理解决方案复杂化。 实现基于表单身份验证的应用程序开发人员在以 Active Directory 方式验证用户时，最好使用 LDAP 绑定或 LogonUser() 这样的 Windows API 来确认用户凭证，也可以生成一个安全上下文，在本章后面的“身份验证”部分对此进行了说明。 实施基于表单的身份验证的应用程序通常会使用 HTTP cookie 或 URL 修改来为用户提供 SSO。ASP.NET 提供了通过加密技术来防止未授权读取并通过数字签名来防止随意篡改的 cookie 保护功能。 本系列文章中的“开发可识别身份的 ASP.NET 应用程序”一文中，详细介绍了开发人员应如何在 Windows 平台上使用基于表单的身份验证。 基本身份验证 与基于表单的身份验证一样，基本身份验证并非真正的网络身份验证协议，因为在进行网络资源验证时它并不以加密的方式来保护用户的凭证。与基于表单的身份验证一样，执行此类身份验证的服务器以明文形式接收用户凭证，然后使用 Windows API 验证用户。与基于表单的身份验证的另一点相同之处是，部署此类身份验证技术的开发人员和系统管理员必须付出巨大的努力来保护应用程序或服务器免遭危害。因此，微软强烈建议在没有 SSL 的情况下不要使用基本身份验证。基本身份验证与摘要身份验证具有相同的 SSO 特征。 单一登录 任何关于身份验证的探讨都少不了一个重要概念，即单一登录 (SSO)。在身份验证进程中实施 SSO 的方式有多种： ? 桌面集成的 SSO。 ? Web SSO。 ? 凭证映射，或企业 SSO。 SSO 完全省去了额外输入用户凭证的过程，也意味着不必再去判断其中所涉及的身份验证安全级别。出于安全性考虑，有一些 SSO 类型可能比其他的更好一些。 此外，Extranet SSO 和 Intranet SSO 这两个术语是指在 Extranet 或 Intranet 情景中实现 SSO 时所采用的技术。Extranet SSO 通常基于 Web，而 Intranet SSO 则会涉及许多类型的应用程序和服务，其中包括 Web 应用程序、胖客户端应用程序和终端会话。 桌面集成的单一登录 安全登录要求用户向网络提供其身份的证明，但是以反复键入密码的方式访问多个资源会令用户感到厌烦。Microsoft Windows 平台利用单一登录功能，跨网络中使用单一用户身份（在 Active Directory 中维护）。由于用来登录到工作站的凭证往往就是用来访问网络资源的凭证，因此用户的登录凭证（用户名和密码组合）将会被缓存到客户端操作系统本地的“本地安全授权”(LSA) 中。用户登录到域中后，在验证到网络资源时，Windows 身份验证将使用这些缓存的凭证来提供 SSO。 为确保良好的安全性，需要用户提供一个经过验证的身份来访问网络资源。通过 SSO，用户只需经过一次系统身份验证即可访问他们有权使用的所有应用程序和数据源，而不必再输入另一个帐户 ID 或密码。 Kerberos 版本5 身份验证协议、NTLM 和智能卡身份验证技术均与微软客户端及服务器操作系统中的桌面登录进程相集成，以为组织 Intranet 中 Windows 域或 Windows 林内的用户提供 SSO 体验。 Active Directory 提供了受信任的第三方，使服务器无需本地存储每个用户的相关信息即可验证用户。 Windows Server 2003 中的高级信任机制（例如跨林信任）允许某个林中的身份在访问其他林中的资源时享用 SSO。 Web 单一登录 由于越来越多的公司都在部署员工、合作伙伴和客户使用的 Extranet 和 Intranet Web 应用程序，因此为用户提供 SSO 体验的能力就变得非常重要。 Web 应用程序与传统的“胖”客户端/服务器应用程序不同，因为它们通常依靠 Web 服务器实现身份验证。这种依赖性使用户可以通过常用方法将身份验证机制添加到单一应用程序（Web 服务器）中，同时还解决了大量服务器托管应用程序的身份验证问题。在 Intranet 环境中，微软服务器和客户端产品通过在 Internet Explorer 和 IIS 6.0 中实施 Kerberos 版本5 身份验证协议来提供 Web 单一登录或 Web SSO，本系列文章的“Intranet 访问管理”一文将对此进行了描述。 不幸的是，Intranet 环境中行之有效的 Kerberos 实现对组织 Extranet 中面向 Internet 的应用程序却束手无策。Intranet 和 Extranet Web SSO 之间的差异是以下三个因素共同作用的结果： ? 部署面向 Internet 的“密钥分发中心”(KDC)（例如 Active Directory 域控制器）过程中固有的困难。 ? 许多浏览器不支持在 HTTP 上进行 Kerberos 身份验证。 ? KDC 协议中原有的漏洞 虽然对部署面向 Internet 的 KDC 过程中固有困难的详细讨论不在本文的论述范围之内，但该问题却是实施部署的一大障碍。 第二个问题对 Extranet 部署的影响通常更为明显。与内部部署不同，软件标准在内部是强制执行的，然而很少有组织能够规定外部客户和商业合作伙伴使用哪种类型和版本的浏览器软件来访问外部应用程序。Microsoft Internet Explorer 6.0 及更高版本是市面上唯一可以买到的支持在 HTTP 上进行 Kerberos 身份验证的浏览器。 解决多个 Web 应用程序 SSO 问题的标准方法是使用会话“cookie”，“HTTP 状态管理机制”提供了对此的详细介绍，在“请求注解”网站上将由 IETFRFC 2109 加以定义。一些独立软件供应商 (ISV) 提供了跨 Extranet Web 应用程序实现 Web SSO 的解决方案。 对于支持 Passport 身份验证的站点，前文详细介绍的 Microsoft Passport 服务也为用户提供了 SSO 体验。 用户可以将 Web SSO 技术与企业 SSO 技术结合起来，如 SharePoint Portal Server 站点，它包括用于访问唯一身份验证目录内旧版应用程序数据的 Web 部件。在此示例中，Web SSO 技术提供对网站的访问，而企业 SSO 技术则提供对旧版应用程序数据的访问。 凭证映射和企业单一登录 “企业 SSO”是指采用凭证映射形式提供 SSO 体验的任何技术。其中，凭证映射是一个必备因素，因为身份验证会涉及多种不同的身份存储或目录。某项服务（运行于客户端或服务器上）可以代表帐户登录到目标应用程序，模拟 SSO 体验。这种服务必须从凭证映射存储或数据库中查找相应的凭证（帐户、密码等等）。 Microsoft BizTalk? Server、Host Integration Server、SharePoint? Portal Server、Windows 凭证管理器以及来自 PassLogix、Protocom 和 Version3 等 ISV 的产品都采用各种不同的企业 SSO 技术来针对遗留系统和使用自身目录进行身份验证的应用程序实现 SSO，甚至用它来实现对不可信 Windows 域中资源的访问。 许多组织都存在拥有多个非信任身份存储却没有实现 SSO 的现象，与之相比“企业 SSO”能够提供更好的用户体验。“企业 SSO”方法应与配置和密码管理方法相集成，以确保无缝的体验和最大程度减少帮助台的呼叫次数。这种方法在最大程度降低总拥有成本的同时还可提供最佳的用户体验。 注意 由于“桌面集成的 SSO”与选项目录紧密集成，而且不需要额外的冗余目录和凭证映射数据库配置和管理，因此要优于企业 SSO。 有关通过“企业 SSO”实现凭证映射的更多信息，请参见本系列文章中的“Intranet 访问管理”一文。 Windows 凭证管理器 Windows XP Professional 和 Windows Server 2003 中包括一项“存储的用户名和密码”功能，它也可提供凭证管理功能。此组件可以根据所尝试的身份验证类型，保存用户凭证，并在以后的访问尝试过程中重新加以使用。 图 6.2.“存储的用户名和密码”支持多组凭证的 SSO 如果应用程序不允许用户保存凭证，用户则必须手动访问“存储的用户名和密码”来设置该资源的凭证。凭证管理器支持以下类型的凭证： ? Kerberos 版本5 协议和 NTLM 身份验证的用户名/密码组合。 ? 使用 SSL/TLS 进行客户端身份验证的 X.509 数字证书。 ? 用于 Web 身份验证的 Microsoft Passport 凭证。 注意 用户可以使用 Windows 凭证管理器通过 SSL/TLS X.509 客户端证书身份验证提供 Web SSO 体验。默认情况下，只要用户拥有一个以上的有效证书，就会看到提示选择身份验证证书的消息。凭证管理器可确保在验证对特定资源的访问权限时自动提供适当的证书。 有关 Windows 凭证管理器的更多信息，请参见本系列文章中的“Intranet 访问管理”一文。 返回页首 授权 授权是应用程序或平台通过对比用户权利和资源安全配置来确定资源访问权的过程。例如，用户可对文件服务器提出验证请求，服务器随后确定用户是否具有读、写或删除文件的能力。 与 Windows Server 2003 操作系统及 Active Directory 相集成的应用程序使用操作系统的内置功能来执行授权。 Windows Server 2003 支持两种授权机制：基于 Windows 访问控制列表 (ACL) 的模拟模型，和基于角色的新型授权管理器。此外，Microsoft ASP.NET 应用程序还可以使用 ASP.NET 角色进行授权。以下部分将详细讨论这两种机制。 Windows 模拟和访问控制列表 Microsoft Windows NT 3.1 引入了模拟和 ACL 模型来为服务和应用程序提供授权。模拟是为实现无缝用户体验和轻松管理而紧密耦合身份验证和授权的产物。 身份验证数据包首先验证用户，然后为该用户构建“安全上下文”。安全上下文代表用户身份和所属的组以及用户的权利。一旦身份验证数据包生成安全上下文，应用程序或服务即可获得允许访问资源的安全上下文。换句话说，服务在尝试访问资源时，可以使用用户的安全上下文（而非服务自身的上下文）获得访问权，在本地模拟用户。 这是一个很重要的概念，因为大多数服务在计算机中都拥有广泛的权限。例如，在运行 Windows 的服务器上提供文件和打印服务的服务器消息块 (SMB) 服务可作为本地系统运行，而且可以访问任何资源。为了根据文件所有者或系统管理员所建立的规则来限制用户对文件的访问，SMB 服务应模拟远程用户。 Windows 授权模型的另一部分是基于对象的 ACL。对象的 ACL 定义了对象的访问级别安全主体（用户或组）。例如，文件的 ACL 可以定义一个用户拥有读取某文件的权限，而另一个用户拥有读取和删除该文件的权限。 操作系统（特别是 NT 对象管理器）是使用此模型访问对象时的最终仲裁者。“NT 对象管理器”将用户的安全上下文与对象的 ACL 加以比较，完成仲裁操作。由于操作系统是最终的仲裁者，因此模拟/ACL 模型的安全特性非常适合多个应用程序可以访问系统资源的方案。 然而，模拟/ACL 模型的某些方面仍有待进一步改进，其中包括： ? 性能。对于同时将内容传送给多个不同用户的服务，使用模拟来切换上下文会增加服务器的负荷，影响应用程序的可伸缩性。 ? 灵活性。使用模拟模型时，应用程序开发人员或服务管理员必须在域级别更改组成员身份之后才能为用户创建新组或角色。域管理员反对为单一应用程序创建大量组供其使用，致使应用程序开发人员只能利用目前现有的组进行工作。 ? 商业规则。模拟/ACL 模型充分表现了对象的授权，却很难描述商业规则逻辑，例如日期时间或其他运行时逻辑。例如，用户可能希望实行一种仅允许特定的人员在特定时间执行特定动作的授权策略。 为克服这些问题，Windows Server 2003 为系统管理员和应用程序开发人员加入了“授权管理器”。授权管理器的 Windows 2000 版本可从 Microsoft.com 的 Windows 2000 授权管理器运行时 下载页面获得。 Windows Server 2003 授权管理器 Windows Server 2003 中的“授权管理器”是新的基于角色的访问控制 (RBAC) 接口。“授权管理器”为开发人员提供了实现以下目标的能力： ? 简化应用程序访问控制管理。 ? 提供精简自然的开发模型。 ? 实现灵活而动态的授权决策。 对于特定任务，“授权管理器”接口将用户与应用程序内的各种角色有机地组织在一起，并在模拟这些角色时给予其访问权限。下图显示了访问某个应用程序的三个不同用户。“授权管理器”将每个用户都映射到在授权策略存储中所定义的角色。 图 6.3.授权管理器如何定义和应用角色 “授权管理器”提供了根据每个应用程序的需求定义和维护逻辑角色及任务的能力。这种根据组织结构表现安全模型的方式简化了访问控制管理。此外，任务和角色的定义有助于为应用程序工作流建模，也有助于通过“授权管理器”为开发人员提供一个以应用程序为中心的自然环境。 “授权管理器”还动态限定运行时赋予的权利。这一功能解决了行业 (LOB) Web 应用程序（例如支出报告应用程序或基于 Web 的购物应用程序）存在的特殊授权问题。 对于这种应用程序，对既定永久对象的访问往往不能做出授权决策。而是需要检查工作流程或包含多个不同操作的操作组，例如查询数据库和发送电子邮件消息。这样的访问决策不仅基于令牌组成员身份，还基于商业逻辑，例如在支出应用程序或工作流完成验证中提交的数量。这些没有既定永久对象的应用程序没有放置 ACL 的位置。这些动态访问决策采用“授权管理器”所提供的动态商业规则（称为 BizRule）形式，易于使用。 BizRule 通常使用在应用程序运行期间检查访问权限时所执行的 Microsoft Visual Basic? Scripting Edition 脚本或 JScript? 例程来实现。如果 BizRule 成功，应用程序便执行所请求的操作。 定义应用程序所用逻辑角色和任务的授权管理器策略可以存储在 Active Directory 或 Active Directory 应用程序模式的应用程序分区中，也可以存储在服务器或网络上的 XML 文件中。 有关使用 Windows Server 2003 授权管理器的 RBAC 的更多信息，请参见 TechNet 上的授权管理器概念 页面。 IIS 6.0 中提供了一个用于说明应用程序如何使用授权管理器角色框架的示例。Windows Server 2003 中包含 IIS 6.0，它通过与“授权管理器”的集成来实现 IIS 6.0 URL 授权。实现这一集成后，Web 应用程序管理员可以根据自定义的用户角色、LDAP 查询和 BizRule 来控制对 URL 的访问。 在 IIS 6.0 中授权用户对网页的访问时，可能需要在 Web 应用程序所用的资源上管理多个自由访问控制列表 (DACL)。Web 应用程序的资源可能包括网页文件、数据库记录和注册表项。为了维护 DACL，管理员必须确切知道每个对象在 Web 应用程序中执行针对性任务必须具备哪些后端权限要求。 IIS 6.0 URL 授权使管理员可以通过授予用户对构成 Web 应用程序的 URL 的访问权限，来简化访问管理。客户端请求 URL 时，IIS 6.0 URL 授权将根据用户角色验证用户的访问权限。必要时，Web 应用程序可以使用授权管理器角色框架来进一步限定对资源和操作的访问。 ASP.NET 授权 ASP.NET 提供了基于角色的授权模型，这种模型使用 Active Directory 组和应用程序派生角色。授权管理器 RBAC 和基于 ASP.NET 角色的授权有一些相似之处，但却通过不同的机制来实现。ASP.NET 角色对于不能归属到更大型应用程序组中的独立应用程序最为有用。 返回页首 信任和联合 有时您可能需要链接两个或多个不同的身份存储，例如在您需要实现合作关系安排或使用不同的外部和内部目录结构时。这种链接使得仅对一个身份存储拥有验证资格的用户可针对另一个身份存储进行验证，即使他们在这个身份存储中没有数字身份，也能够成功进行验证。这种安排称为信任关系。 信任关系存在于定义了安全边界的不同领域之间。在 Windows NT 和 Active Directory 环境中，可以在域之间建立信任。在 Windows Server 2003 中，可以在林结构之间建立更高的信任级别。但林结构内部各域之间具有隐性的信任关系。 与 Windows Server 2003 及 Active Directory 相集成的应用程序使用操作系统的内置功能来建立和维护信任。 管理信任关系 在较高级别，信任关系只提供了一种在领域之间进行身份验证的方法。但是，信任机制变得越来越复杂，因为若要使身份验证和后续授权真正具备实用价值，必须在领域之间执行许多任务。 本节的其余部分将介绍 Windows 平台中可用的信任类型，以及如何使用信任来解决身份和访问管理问题。 外部信任 Microsoft Windows NT Server 中引入了域信任的概念。Windows NT 域信任（现称外部信任）允许一个 Windows NT 域信任另一个 Windows NT 域，将其视为一种特权来验证隶属于该域的用户。外部信任既可以是单向的也可以是双向的，信任的方向决定着身份验证和访问可能发生的方向，如下图所示。 图 6.4.信任域和被信任域之间的关系 Windows NT Server 4.0 模型非常灵活，它允许各部门根据需要采用自下而上的基层部署模式来实现 Windows NT 4.0 域。其问题在于，由于各个大型公司引入了越来越多的域，使得管理外部信任关系逐渐成为一个非常严重的问题。因为每个部署的域都可能拥有 n 多个信任关系，因此要管理的信任关系总数随着域数量的增加而迅速增加。拥有 4 个域的小型公司可能只需管理 12 个不同的信任关系，而拥有 10 个域的较大型公司则可能需要管理 90 个信任关系。拥有 100 个域的公司则要管理数量更为庞大的信任关系。 Windows 2000 Server 林 为简化大型组织中的信任管理，Microsoft Windows 2000 Server 引入了 Active Directory 林的概念。 Active Directory 林保留了 Windows NT Server 4.0 随需式由下而上信任模型的灵活性，同时解决了执行自上而下信任管理的问题，如下图所示。 图 6.5.单一 Windows 2000 Server 林 此图形表示一个拥有单一 Windows 2000 Server 林的组织。林结构内部的信任关系是隐式信任，其功能与双向外部信任相同，只是这些信任关系是向同一林中添加域（可看作林中的树）时自动创建的。林结构内部的域是有层次的，使组织的网络能够反映出组织的业务状况。 遗憾的是，Windows 2000 Server 并没有最终解决信任关系问题。这种信任关系假设大多数公司在其整个网络和资源范围内部署单一林结构。然而，众多原因决定了这种假设并不成立。 例如，一些非常庞大的组织没有集中的信任管理组负责管理组织的所有资源。因此在这种组织中，组织各个不同部分间存在目录服务体系结构必须实现的自然安全边界。另一个常见的例子就是，对单独 Intranet 林和 Extranet 林的需求。尽管开发人员可以将 Extranet 设计为 Intranet 林的一个域，但是出于安全考虑，许多组织还是希望在 Extranet 和 Intranet 之间有更大程度的隔离。 有关 Windows 域和林安全边界特性的更多信息，请参见 Microsoft.com 上的“创建和增强安全边界”。 对于具有多个 Windows 2000 Active Directory 林但又希望在不同林的域之间使用信任关系的组织来说，必须在不同林的各域之间建立显式信任关系。与在每个 Windows NT Server 4.0 域之间建立信任关系相比，这种配置的实现只是稍微简单了一点点而已，所以必须找到一种更为优秀的解决方案。 Windows Server 2003 林信任 为简化多个林的部署，Windows Server 2003 建立了林信任的概念。林信任允许管理员通过单一信任关系联合两个 Active Directory 林，以在两个林之间提供无缝的身份验证和授权体验。林信任是两个林的根域之间的单一信任链接；它可以在每个林中的所有域之间建立起一种可传递的信任关系。例如，如果“林 A”信任“林 B”，则通过林信任，“林 A”中的所有域将信任“林 B”中的所有域。下图说明了这一概念： 图 6.6.Windows Server 2003 林信任关系 但是，林信任不会跨林传递。也就是说，如果“林 A”信任“林 B”，而“林 B”又信任“林 C”，“林 A”并不会自动信任“林 C”。 有关使用和配置 Windows Server 2003 跨林信任的更多信息，请参见 Microsoft TechNet 上的在 Windows Server 2003 中规划和实施联合林 页面。 使用林信任 林信任使 Windows Server 2003 中的联合林概念成为可能。前面提过，林信任允许在两个林中所有域之间传递信任关系；这种信任建立在两个林的根域之间。 林信任既可以是单向信任，也可以是双向信任。在上图中，“林 A”和“林 B”之间的信任关系是双向的。因此，“林 A”中的用户可以针对“林 B”中的资源进行验证，“林 B”中的用户也可以针对“林 A”中的资源进行验证。除身份验证外，林信任还支持授权，从而每个林中的资源所有者都可以将主体从另一个林添加到 DACL 和组中，或者根据这些组创建角色。 使用影子帐户代替信任 有时，一些安全性要求会禁止在林之间使用 Windows 信任机制。在这种情况下，可以在一个目录中创建影子帐户来镜像另一个目录中的帐户。影子帐户通常只从源领域镜像特定应用程序或方案所需要的身份信息。为满足安全性要求，特别敏感的身份属性将不会出现。敏感信息包括身份的社会保障号或用户密码等信息。 尽管使用员工影子帐户这一概念可能不太直观，但却非常适合这样一种情况：组织使用 Active Directory 的 Intranet 实例进行身份验证，又想具有可供员工使用的 Extranet。在 Extranet 上验证员工身份有以下两个选择： ? 使用从外围网络（也称 DMZ、外围安全区或屏蔽子网）到 Intranet 的林或域信任。 ? 在外围网络中创建影子帐户。 第一种方式需要开放许多端口，从而可以允许一条路径通过分隔外围网络和 Intranet 的防火墙。这种方式适用于许多组织，但还有一些组织需要将其外围网络和 Intranet 之间彻底隔离。 对于需要严格网络隔离的组织而言，使用影子帐户可能是最好的选择。微软建议通过自动化机制来创建影子帐户，例如 Microsoft Identity Integration Server 2003, Enterprise Edition (MIIS 2003 SP1) 中提供的机制。在某些允许安全性较低的服务器（比如 Extranet 中的服务器）采用非密码身份验证机制的场合，影子帐户甚至能提高网络安全性。这种示例包括基于安全套接字层 (SSL) 3.0 的身份验证和传输层安全 (TLS) 1.0 客户端证书身份验证，或一次性密码身份验证机制（例如 RSA Security Inc. 的 SecurID 双因素身份验证产品）。 公钥基础结构信任 公钥基础结构 (PKI) 是由以下要素组成的一套体系：数字证书、认证机构 (CA) ，以及其他通过公钥加密来检查和验证电子事务中每一方有效性的注册机构。但要检查和验证有效性，每一方都必须信任证书的颁发者（通常是 CA）。 对于 Windows 用户、计算机和服务，如果受信任的根认证机构存储中存在根证书副本以及有效的认证路径，则会建立证书颁发机构中的信任。有效的认证路径表示认证路径中没有任何被吊销或已过期的证书。认证路径中包含颁发给认证层次结构中每个 CA（从从属 CA 至根 CA）的所有证书。 例如，对于根 CA，认证路径就是一个证书，是其自签名的证书。对于从属 CA，它仅位于认证层次结构中根 CA 之下，其认证路径使用两个证书：其自己的证书和根 CA 证书。 若要为计算机和计算机托管的应用程序建立 PKI 信任，最简单直观的方法是将根证书导入受信任根认证机构存储中。例如，如果 Contoso Pharmaceuticals（一个虚构的组织）的 Web 服务器将 Fabrikam Inc.（另一个虚构的组织）的根证书 CA 安装到根认证机构的存储中，Contoso Web 服务器就会信任由 Fabrikam CA 所颁发的任何有效证书。但这一流程只是建立事务的信任部分，而不会在 Web 服务器上建立身份或上下文。若要创建从身份到上下文的映射，需要执行一些其他操作，例如将证书中的某些信息映射到 Active Directory 中的安全主体。 有关使用 Active Directory 证书映射功能进行相互身份验证的更多信息，请参见 Microsoft Windows 2000 Server 网站上的循序渐进指南：将证书映射到用户帐户 页面。 虽然受信任根认证机构的存储机制相当容易部署，但它无法满足在建立两个组织（如 Contoso 和 Fabrikam）间联合信任这类复杂场合下的安全性要求。可以考虑 Contoso 和 Fabrikam 用户都可以提供有效证书来访问 Contoso 网站这种方案。在这种情况下，外部 Active Directory 中将包含来自 Contoso 和 Fabrikam CA 的证书映射。 一种操作是建立基于证书主题的映射，例如：E=[e-mail]。这种方法的问题是没有绑定信任。未绑定的信任意味着 Contoso 愿意完全信任 Fabrikam，不会颁发主题为 E=[e-mail] 的证书，此处 [e-mail] 是 Contoso 组织中的用户，而不是 Fabrikam 组织中的用户。这种情况下，证书持有者可能会获得对 Contoso 站点上敏感信息的访问权限。出现这个问题并不是因为 PKI 信任本身存在不足，而是因为证书定义过于广泛。解决这一问题的办法是建立可控性更高的 PKI 信任机制，使 Fabrikam 只能为 @fabrikam.com 域颁发证书，而不能为 @contoso.com 域颁发证书。 限定从属 在 Windows 2000 网络中，根本无法实现 CA 层次结构的真正交叉认证。唯一可替代的方法是定义信任特定 CA 和限制证书用途的证书信任列表 (CTL)。 Windows 2003 Server 中所引入的限定从属是交叉认证 CA 层次结构的过程，此过程使用基本策略、命名和应用程序约束条件来限制从合作伙伴 CA 层次结构或同一组织内的辅助层次结构中接受的证书。通过限定从属，CA 管理员可以明确地定义其组织信任合作伙伴 PKI 所颁发的证书。限定从属还提供了根据策略原则在组织内划分和控制证书颁发的方法。 限定从属还允许在不同信任层次结构中的 CA 之间建立信任。这种类型的信任关系还可称为交叉认证。通过这种信任关系，限定从属不再限定于从属 CA。使用一个层次结构中的从属 CA 和另一个层次结构中的根 CA 可以在两层次结构之间建立信任。 限定从属允许在 PKI 中为域内部和域之间设置额外的信任条件，以扩展信任层次结构。通过限定从属，信任层次结构中的每个限定从属 CA 可以具有不同的规则，来控制其证书的颁发方式及使用方式。 有一个示例可以说明如何使用信任条件来解决先前所提到的证书定义过广的问题，即在 Contoso 和 Fabrikam 层次结构之间建立交叉认证时使用命名空间约束条件。通过这种方式，Contoso 将只接受指定了 fabrikam.com 域的 Fabrikam CA 证书。 有关限定从属的更多信息，请参见 Microsoft TechNet 上的限定从属 页面。 实施联合 联合身份管理是基于标准的技术和信息技术，支持跨组织和平台边界的分布式标识、身份验证及授权。联合系统可以跨组织边界进行互操作，并可以将使用不同技术、身份存储、安全方法和编程模型的过程连接起来。在联合系统内部，组织需要通过一种标准化的安全方式来表示为受信任的合作伙伴和客户所提供的服务。组织还必须实施商业运作所仰赖的策略，如： ? 信任哪些其他组织和用户。 ? 接受哪些类型的凭证和请求。 ? 实施哪些隐私策略。 Microsoft Windows Server 2003 R2 引入了 Active Directory 联合服务 (ADFS)，使得组织可以安全共享用户的身份信息。ADFS 提供了 Web 单一登录 (SSO) 技术，以在单一联机会话的生命期内实现用户对多个 Web 应用程序的验证。ADFS 通过跨不同安全和企业边界安全共享数字身份、权利或“声明”的方式实现了此目标。 ADFS 与 Active Directory 以及 Active Directory 应用程序模式 (ADAM)} 一起工作。具体来说，ADFS 使用 Active Directory 的企业级部署或 ADAM 的实例进行工作。在使用 Active Directory 时，ADFS 可以利用 Active Directory 中强大的身份验证技术，包括 Kerberos、X.509 数字证书和智能卡。在使用 ADAM 时，ADFS 使用轻型目录访问协议 (LDAP) 绑定来验证用户身份。 ADFS 支持在 Internet 上应用分布式身份验证和授权。ADFS 可集成到组织和部门的现有访问管理解决方案中，将组织所使用的条款转换为联合时商定的声明。ADFS 可以创建、保护和检查在组织之间移动的声明。同时它还可以审核、监视组织和部门间的活动，以确保事务处理的安全。 有关 ADFS 的更多信息，请参见 Microsoft.com 上的 Windows Server 2003 R2 中的 Active Directory 联合服务 (ADFS) 概述 。 返回页首 安全审核 审核提供了监视访问管理事件和身份对象更改的方法。安全审核通常用于监视问题或违反安全性事件的出现。Windows 安全事件日志等技术、Windows 管理接口 (WMI) 以及 MOM 2005 SP1 等产品都可以提供全面的安全审核和报告。 审核目录服务 Active Directory 和 ADAM 与 Windows Server 2003 审核完全集成。Windows 安全事件日志反映目录对象和属性的更改，也反映目录对象和属性的授权策略、架构和组策略。您可精确控制如何配置基于成功、失败或尝试操作的可审核事件。 审核身份验证 上述 Windows 身份验证机制都会在 Windows 安全事件日志中生成审核。可以使用组策略配置要生成的审核（例如身份验证失败或成功），也可以手动配置每一台服务器。 Windows Server 2003 还通过根据身份验证类型对身份验证进行分类，提供了对身份验证事件的精确控制。例如，一种类型的审核跟踪控制台登录，而另一种类型的审核则跟踪网络资源的身份验证尝试。身份验证审核始终可以跟踪到唯一的安全主体。 一旦启用了用户对身份存储的验证，下一步骤即是需要指定用户可以访问的资源。授权是控制资源访问权限的过程。 审核授权 Windows Server 平台完全支持授权操作的审核。对于模拟/ACL 模型，“NT 对象管理器”根据审核配置来报告对资源访问的审核。此项配置可以通过组策略来实施，也可以在每台服务器上手动实施。系统生成这些审核之后，审核事件将会出现在“系统安全事件日志”中。 审核配置功能非常精确，审核内容的指定也很方便，例如可以轻松指定仅审核文件的失败访问尝试。因为身份验证和授权机制紧密地集成在一起，因此授权审核根据其唯一安全标识符 (SID) 来指定访问资源的安全主体。 “授权管理器”支持运行时审核和“授权管理器”策略更改审核。运行时审核使用失败或成功的审核记录来报告应用程序初始化、上下文创建与删除和对象访问。“授权管理器”策略更改审核可以报告策略存储的任何变化，包括对策略和策略定义的审核。 在单一安全领域或安全目录林内的身份验证和授权过程相对简单一些。然而，身份和访问管理往往需要面对链接两种不同安全领域的要求，而这就需要在目录服务之间或组织之间实现某种形式的信任。下一章将探讨此项要求。 审核信任 Windows Server 2003 会详细而充分地审核信任配置。您可以审核信任的创建、删除和修改等事件。信任审核事件会显示在“安全事件日志”中。