使用 Authorization Manager 对多层应用程序进行基于角色的访问控制

使用 Authorization Manager 对多层应用程序进行基于角色的访问控制

作者：Dave McPherson（Microsoft Corporation）

致谢：非常感谢 Jason Rush、Praerit Garg、Don Schmidt、Paul Leach 和 Doug Bayer 的支持。

本页内容

	介绍
	授权策略存储
	应用程序管理
	审核
	应用程序设计过程
	开发 Authorization Manager 应用程序
	性能
	特定于环境的设计事项
	Internet Information Services 6.0 URL 授权
	场景：Web 开支应用程序
	场景：使用带有自定义主体的授权管理器

介绍

在 Windows Server 2003 家族中，Authorization Manager（授权管理器）为 Windows 平台中的应用程序授权引入了一种新的模型。Authorization Manager 为业务应用程序提供了一种易用的授权框架，在这种框架中，您必须根据用户在组织或应用程序中的角色授予用户访问权限。为了达到这种要求，应用程序常常创建授权机制的自定义实现，这增加了开发成本和管理复杂性，因为存在着不同的授权模型。Authorization Manager 给应用程序提供了基于角色的访问控制，这使得管理更加容易而基于 Web 的应用程序或业务应用程序的开发更加自然。

ACL 和业务应用程序

由于在 Microsoft Windows NT Server 4.0 中引入了 Private Object Security API，所以 Windows 操作系统已经支持在应用程序的访问控制中使用 ACL。在 ACL 模型中，您可以将任意访问控制列表（DACL）附加到可保安全的对象中，并可以通过调用 AccessCheck 应用程序编程接口（API）来作出访问决定，该接口查看令牌中的用户组成员资格并且将它们与 ACL 的内容进行比较，以决定用户是否具有请求的访问权限。ACL 模型对于许多类型的应用程序都是非常理想的。定义明确的持久性对象的资源管理器（如：NT 系统注册表）可以适当地使用 ACL 模型来提供对象级访问控制。在这些类型的应用程序中，始终可以根据用户对现有系统的访问请求来作出访问控制决定。将来，使用 ACL 模型的应用程序应该使用 AuthzAPI，AuthzAPI 是在 Windows XP 和 Windows Server 2003 家族中引入的。它提供了性能和灵活性增强（与 Windows NT Private Object Security API 相比）。要获得更多关于 AuthzAPI 的信息，请参见 Microsoft Platform Software Development Kit（Microsoft 平台软件开发工具包）。

一些业务（LOB）应用程序中存在着完全不同的授权问题，比如：Web 开支报告应用程序或购物应用程序。对于这些应用程序，授权决定并不确定对定义明确的持久性对象的访问。相反，它们验证工作流或执行多个不同的操作，比如查询数据库和发送邮件。在 LOB 应用程序中，访问决策常常是根据业务逻辑作出的，比如在开支应用程序中提交的数量或工作流完成的验证，而不只是基于令牌组成员资格。不包含定义明确的持久性对象的应用程序没有空间来存放 ACL，因此 ACL 模型可能难于应用于这些应用程序。

基于角色的访问控制

传统的访问控制管理模型是基于对象的。在这些模型中，访问控制是在对象或对象容器中指定的（例如：在 ACL 中），而管理员必须到对象中查询和指定对对象的访问。这些模型需要管理员将组织授权策略转换成对象上的权限：每个对象都有授予组织中不同的用户和组的访问权限列表。基于角色的访问控制（RBAC）简化了访问控制管理，并且允许根据用户工作角色来管理权限，从而在组织中提供了更好的可管理性。

可以通过使用组来实现一些基于角色的访问控制的目的。一个组对应着一个雇员角色，而应用程序管理员可以通过授予在对象的 DACL 中授予组权限来指定角色所需要的权限。随着对象集合的不断增加，管理员需要管理的地方的数量也在不断地增加。连续使用资源组和用户组可以帮助将其工作量减少到最低限度，但是这需要不断的实践和管理员之间的协调配合以及资源组的精确定义。这些过程都会减慢管理进程，因此管理员常常避免使用它们。

加之，随着对象的数量的增加，跨应用程序查询授予特定组或角色的访问权限会变得越来越困难。为了精确地确定给用户或组授予了何种权限，管理员必须检查每一个对象上的权限。虽然继承功能看起来简化了这方面的工作，但是每个对象都避免继承权限的能力仍使得有必要查看每个对象，以完全理解授权策略。由于有太多的对象需要查询，所以有时就很少检验关于特定组或用户的访问控制状态。

基于角色的访问控制试图允许管理员根据公司的组织结构来指定访问控制。RBAC 通过创建称为角色（role）的新对象来达到此目的。您可以给用户分派执行某种工作职能的角色。然而，与组不同的是，角色将授权权限定义在资源的某些局部上。在 RBAC 模型中，管理员使用角色来管理权限和分派。例如，公司可能创建一个称为销售经理（Sales Manager）的角色，销售经理需要这个角色来满足他们的工作需要。当雇佣销售经理时，就给他们分派销售经理角色，而他们可以立即具有这份工作所需的全部权限。当他们离开销售经理的职位时，就会被从销售经理角色中删除，并且不再具有销售经理的访问权限。由于角色使得可以根据公司的组织模型来授予访问权限，所以对于管理员来说，指定访问控制更显得直观和自然。图 1 标识了角色、用户和权限之间的关系。在这个模型中，角色是授予权限的对象，而且给用户分派了角色。

图 1：基于角色的访问

RBAC 将用户的工作角色映射到应用程序权限，这样就可以根据用户工作角色来完成访问控制管理。RBAC 系统将用户角色成员资格转换成应用程序权限。由于权限是在角色上授予的，所以可以在角色上查询和更改权限，而无需检查特定的资源。在大多数环境中，一旦建立了角色权限，就很少会对角色权限进行更改（与角色分派中的更改相比）。这意味着管理员将必须设置角色，比如：雇员（Employee）、经理（Manager）和管理员（Administrator），但是一旦角色创建完毕，管理员就将管理角色中的成员而不是对象上的权限。

Authorization Manager 概念模型

Authorization Manager 是一组基于 COM 的运行时接口，允许应用程序轻松地管理和检验客户端请求，以便执行应用程序操作。另外，Authorization Manager 提供了 Microsoft Management Console（MMC）插件，应用程序管理员可以使用该插件来管理用户角色和权限。

Authorization Manager：

•	可以简化业务应用程序中的应用程序访问控制管理。
•	可以提供简洁而自然的开发模型。
•	可以启用灵活、动态的授权决策。

在一般情况下，您可使用术语主题（Subject）、资源（Resources）和权限（Permissions）来定义访问控制模型。主题常常是用户对资源进行的操作。访问是由一组权限控制的，这组权限允许主题对资源执行特定的操作。访问控制的管理很少直接处理这些构造，而更为常见的就是管理主题、资源和权限的集合。您通常在组中管理主题或用户，而在特定于应用程序的集合（比如：目录或组织单位）中管理资源。虽然可以直接授予权限，但是常常将权限分组到更高级别的权限，比如：完全控制（Full Control）。这些集合使得在有多个主题、资源或权限的环境中进行授权管理成为可能。应用程序管理员必须使用这些集合来制订应用程序的授权策略，这样每个主题就都有合适的权限来使用应用程序资源。

传统的资源管理器存储授权策略以及策略应用的资源。例如，文件中的 ACL 是由资源管理器存储的并且在逻辑上与该文件相关联。在 Authorization Manager 模型中，授权策略数据与授权策略存储中的对象是分开存储的。应用程序标识应用程序可以执行的操作或任务，并且在应用程序安装时在授权存储库中加以声明。管理员通过定义角色（根据执行组织中的某项工作所需要的任务和操作）来管理授权策略。定义角色、任务和操作以及给角色分派用户和组的信息都存储在授权存储库中。应用程序在运行时查询授权策略来确认已经授权客户端对资源执行所请求的操作。Authorization Manager 提供 API 来管理授权策略并检查管理员的访问控制和用户接口的有效性，这样他们就可以管理受权策略存储。下图展示了 Authorization Manager 为查询应用程序和管理授权存储库而提供的授权存储库的组合，并展示了每个 Authorization Manager 对象之间的关系。

图 2：Authorization Manager 中的对象关系
查看全尺寸图片。

定义

这一部分介绍了 Authorization Manager 用来管理授权策略的对象。

操作（Operation）：资源管理器使用低级权限来标识安全过程。可能需要几种操作来执行一项有意义的任务。对于管理员来说，操作常常是不公开的或没有意义的。操作范例可以是 WriteAttributes（写入属性）或 ReadAttributes（读取属性）。任务（Task）：低级操作集合。任务用于确定需要哪些低级操作来完成对管理员有意义的某些工作单元。任务范例可能就是更改密码（Change Password）。任务还可以包含其他任务。例如，称为管理用户帐户（Manage User Accounts）的任务可以包括更改密码（Change Password）、重新设置密码（Reset Password）、禁用帐户（Disable Account）等任务。角色定义（Role Definitions）：特定角色所需的权限的集合，其中，权限可以是任务，也可以是操作。注意，该定义类似于任务的定义。角色（Role）：用户为完成他们的工作所必须具有的权限的集合。角色应用于一组对象，而用户分派给角色。BizRules，也称为授权脚本（Authorization Scripts）：附加到任务对象的脚本，在访问请求时运行。它可以使用只是在运行时才可用的信息（比如：“当天时间”或“请求的美元数额”）来做出授权决策。作用域（Scope）：使用完全不同的授权策略的对象或资源的集合。作用域可以代表物理集合（如：文件夹），也可以代表更复杂的资源集合（如：*.doc）。应用程序可以将作用域用作组资源必需的一部分，而且在应用程序检查用户的访问时必须能够将请求的资源映射到其作用域。应用程序组（Application groups）：只可应用于授权存储库、授权存储库内的应用程序或应用程序内的作用域的组。Authorization Manager 实施两种类型的应用程序组。应用程序基本组（Application basic groups）：属于应用程序组的一部分，为一组特定的应用程序、单个应用程序或应用程序内的作用域而维护的成员列表（Active Directory 用户或组或其他的应用程序组）。应用程序组还可以标识非成员，这是考虑到会出现一些异常的情况，比如一个大组可以与一个小一些的组或被排除在外的某个特殊的用户一起使用。LDAP 查询组（LDAP-query groups）：属于应用程序组的一部分，由轻量级目录访问协议（Lightweight Directory Access Protocol，LDAP）在特定的 Active Directory 用户帐户属性中定义的组。可提供灵活的组成员资格，可根据用户帐户属性进行定义并对用户帐户对象保持更新。

返回页首

授权策略存储

当初始化使用 Authorization Manager 的应用程序时，它从存储库加载授权策略信息。Authorization Manager 为在 Active Directory 或 .xml 文件中存储授权策略提供支持。

重要须知：因为授权策略信息是由 Active Directory 存储的或存储在 NTFS 文件中，所以其通过 Active Directory 或 NTFS 的安全性功能加以保护，而直接对存储进行的更改的审核支持是由该存储库所在的系统进行处理。另外，包含授权策略存储库的系统中的管理员具有很高的访问存储库的权限。因此，授权策略存储必须位于受信任的系统中。

Active Directory Authorization Manager 存储

要使用 Active Directory 来存储 Authorization Manager 策略，该域就必须具有 Windows Server 2003 的功能级别。Windows Server 2003 家族中的 Active Directory 包含 Authorization Manager 对象的模式更新。当使用 Active Directory 存储时，Authorization Manager 为存储库本身和每个应用程序组、应用程序、操作、任务、角色和作用域创建 Active Directory 对象。作用域对象可以包含在该作用域中所创建的任务、角色和组。

当使用 Active Directory 授权策略存储库时，应用程序控制何时加载应用程序对象。当应用程序连接到策略存储库时，存储库全局属性（包括存储库级组在内）就与每个应用程序的报头信息一起进行本地缓冲。当应用程序使用 OpenApplication 方法来初始化其授权策略时，每个作用域的应用程序属性、角色、任务、操作、应用程序组和报头信息就都加载到内存中。一旦加载了应用程序，它就在内存中保持缓冲状态，直到应用程序对象被释放为止。作用域是按需加载的；或者是在第一次对 AccessCheck 的调用中指定作用域时，或者是在使用 OpenScope 方法显式加载作用域时。一旦加载了作用域，它就在内存中保持缓冲状态，直到应用程序对象被释放为止。

Active Directory 不支持在多个对象或属性中强制事务编写，因此由两个管理应用程序同时编辑存储库是可能的。在这种情况下，存储库可能会被破坏。正因如此，我们建议应用程序定期备份它们的授权存储库。如要获得更多关于 Active Directory 备份和恢复工具的信息，请参见 Windows Server 2003 帮助中的“Active Directory”。

Active Directory 管理员需要考虑的部署事项

应用程序管理员可以从使用 Active Directory 存储授权策略中受益。Active Directory 存储允许应用程序利用现有的域基础结构对应用程序提供存储、可用性、冗余度和授权策略的分布。部署 Authorization Manager 的 Active Directory 管理员应该考虑下列信息：

域模式要求

Authorization Manager Active Directory Store 要求域位于 Windows Server 2003 功能级别。

Authorization Manager Active Directory 对基础结构的影响

Authorization Manager 是运行在应用程序服务器中的运行时，不在域控制器中运行任何应用程序或服务。Active Directory 可以用于存储授权策略数据。

当初始化和下载所需的应用程序作用域策略时，使用该策略的应用程序下载应用程序策略信息。当应用程序读取该策略信息时，这种读取对域控制器的影响将会改变。应用程序或作用域的授权策略的大小将随着作用域中角色的数量、任务、操作和组的改变而改变。虽然应用程序组的大小可以改变，但是建议您不要将应用程序组用于大型组，以便应用程序的性能不受影响。尽管组和角色的大小可以改变，但是它可能与 Active Directory 组相类似。读取组或角色所耗费的处理时间与读取包含相同数量的成员的 Active Directory 组的成员所耗费的处理时间一样多。虽然应用程序组可以有与 Active Directory 组相同的最大容量，但是它通常比 Active Directory 组小一些，因为它们仅供应用程序使用。当需要包含 5000 个以上的成员的组时，如果可能的话，我们建议大家使用 Active Directory 组来代替应用程序组。

接近要求

应用程序需要对 Authorization Manager 策略进行高质量的访问。虽然在窄带场景中单个应用程序的执行可能是可接受的，但是除非它们具有小型授权存储库，否则域控制器通常还是应该位于应用程序服务器的局域网（LAN）中

复制

授权策略存储库被复制到存储授权策略的域的所有域控制器中，而且林中的每个全局目录服务器内都引用了 Authorization Manager 对象。

单独的域或林可以用于存储 Authorization Manager 策略。您可以选择这样做来将域内的复制流量降到最低，从而将帐户域内的域控制器上的负载降到最低，也可以选择让单独的管理员来管理 Authorization Manager 策略存储库。使用单独的域或林需要在存储用户帐户的域（帐户域）和存储 Authorization Manager 的域（Authorization Manager 存储域）之间建立正确的信任。需要的受信任配置取决于 Authorization Manager 策略的管理员的帐户在什么域中以及应用程序服务器和所有后端资源在哪个域中。

在 Active Directory 中部署 Authorization Manager 存储库

下面给出了关于在 Active Directory 中部署 Authorization Manager 存储库的循序渐进的指导。

1.	选择 Authorization Manager Active Directory 存储库的位置 要在 Active Directory 存储中部署 Authorization Manager，您必须选择存储库的位置。建议管理员在域的 Program Data 容器中创建一个新的组织单元（OU），并且在新的组织单元中创建一个存储库对象。这个建议不是强制性的。如果应用程序在除 Program Data 以外的容器中有数据，您就可以将 Authorization Manager 存储库放入其中。 Authorization Manager 不能放在非域命名上下文（也称为 应用程序分区）中。
2.	创建 Authorization Manager 存储库 应用程序可以通过 Authorization Manager API 在 Active Directory 本身中创建 Authorization Manager 策略存储库，而管理员也可以通过使用 Authorization Manager MMC 来创建存储库。为了达到此目的，尝试创建存储库的用户或应用程序必须在上一步选择的容器中拥有创建子对象（Create Child Object）权限，并且必须知道该容器的专有名称。 要了解更多关于使用 Authorization Manager MMC 插件创建存储库的信息，请参见 Authorization Manager 帮助中的“使用授权存储库”章节。
3.	角色和授权存储库访问 如果应用程序管理员使用程序创建存储库，那么他们就应该已经具有管理存储库的权限。如果存储库由 Active Directory 管理员手动进行创建，则管理该存储库的权限就必须赋予使用该存储库的应用程序管理员。可以使用 Authorization Manager MMC 来授予应用程序管理员访问权限，以便管理授权策略存储库。该存储库内的授权策略由应用程序管理员进行管理。Authorization Manager Active Directory 存储允许应用程序管理员委托应用程序的管理和存储库内的作用域。 由于使用授权策略的应用程序服务帐户必须能够读取策略存储库，所以应用程序服务帐户必须包括在读者（Reader）角色中，而读者角色可以属于适当的存储库或应用程序或存储库内的作用域。
4.	启用 Windows 授权访问组 注意：只有当应用程序设计人员使用 InitializeClientContextFromName 和 InitializeClientContextFromStringSID 方法创建应用程序内的客户端上下文对象时，才需要完成这一步。使用 InitializeClientContextFromToken 的应用程序则不需要这一步。如果您不敢肯定应用程序服务器将使用哪些 API，您可以向应用程序管理员或设计人员询问，他们应该会知道。 这些方法试图读取 Active Directory 中用户 token-groups-global-and-universal 属性，以便获取用户的 Active Directory 组成员资格信息。要读取这种信息，应用程序服务帐户必须具有对每个用户对象的该属性的读取（Read）权限。 如果该域是为“Windows 2000 以前版本的兼容访问模式”配置的（即“所有人”（Everyone）组在“Windows 2000 以前版本的兼容访问”组中），则在默认情况下，“经验证的用户”（Authenticated Users）组将有权调用 InitializeClientContextFromName 或 InitializeClientContextFromStringSID 方法。如果该域是针对 Windows 2000 和“Windows Server 2003 兼容访问”设置的，则在默认情况下，只有“经验证的用户”组在“Windows 2000 以前版本的兼容访问”组中。在这种情况下，应用程序服务帐户将具有调用 InitializeClientContextFromName 或 InitializeClientContextFromStringSID 方法所需的权限。如果该域已经被锁定（即 Active Directory 管理员更严格地限制了默认访问权限），则“Windows 2000 以前版本的兼容访问”就有可能为空，在这种情况下，服务器在调用 InitializeClientContextFromNameOfSID 接口时可能会失败。 如果出现这样的情形，为了授予服务帐户访问的权限，建议您首先将服务帐户添加到“Windows 授权访问”（Windows Authorization Access）组中，然后授予“Windows 授权访问”组访问每个用户 token-groups-global-and-universal 属性的权限（如果它还不具有这种访问权限的话）。如要了解更多关于“Windows 授权访问”组（属于 Windows Server 2003 家族中的一个新组），请在 Microsoft 知识库（http://support.microsoft.com/）中搜索该术语。

Authorization Manager 中的 XML 文件存储

Authorization Manager 支持通过 .xml 文件存储授权策略（即存储在 NTFS 卷中）。XML 存储库可以保存在与使用 Authorization Manager API 的服务器应用程序相同的计算机上，也可以进行远程保存。

为了支持对象的重命名，XML 格式包含全局惟一的标识符（GUID）。因此，您不应该直接编辑 .xml 文件。此外，XML 模式目前尚未发布。您可以通过 Authorizati