Windows Server 2003 中的授权管理器代表着基于角色的安全管理的重大改进，使其具有更高的可伸缩性、灵活性更大并且更易于实现。使用授权管理器，可以定义角色以及这些角色可以执行的任务。可以嵌套角色以继承其他角色的特征，并且可以定义应用程序组。此外，授权管理器还使您可以使用脚本来动态修改权限，并且它使您能够在可以存储于 Active Directory 内的安全策略中包装安全逻辑。授权管理器还包含一个易于使用的用于运行访问检查的 API。作者将对上述所有主题进行讨论，并用有效的示例对它们进行演示。
目录
授权管理器简介
示例应用程序：公司库
授权存储区
AzMan 运行库接口
存储区、应用程序和范围
应用程序组
脚本
支持授权脚本
审核
小结
基于角色的安全是从 Windows NT 的第一个版本开始在 Windows 平台上发展而来的。使用角色，操作系统可以通过检查称为 BUILTIN\Administrators 的组的安全上下文做出一些决定，例如，进程是否有特权。操作系统基于该逻辑角色做出决定（例如，是否让您安装服务或设备驱动程序）。在安装操作系统时，您可以通过将相应的用户添加到 Administrators 组来选择谁将承担该角色。
Microsoft 事务服务 (MTS) 和 COM+ 试图使基于角色的安全成为一种让应用程序开发人员感觉愉快的功能，并且为 COM 服务器提供了一个简单的、基于角色的授权基础结构。目标是为多层服务器应用程序启用受信任的子系统模型，其中应用程序服务器受到后端资源的信任以批准请求。通过及早执行授权，可以避免向后端服务器委托客户端凭据的需要。委托充满了从潜在的安全漏洞到可伸缩性问题等大量问题。
如果您一直在寻找中间层中的通用授权解决方案，那么您的搜索可以告一段落了。
授权管理器简介
授权管理器（通常称为 AzMan）是 Windows 的一种通用的、基于角色的新安全体系结构。AzMan 与 COM+ 无关，因此它可以用在任何需要基于角色的授权的应用程序中，包括 ASP.NET Web 应用程序或 Web 服务、基于 .NET Remoting 的客户-服务器系统等等。在撰写本文时，授权管理器仅在 Windows Server?2003、Windows 2000 的 Service Pack 4 中提供，并且预计作为 Windows XP 未来的 Service Pack 发布。
AzMan 有两个部分：运行库和管理 UI。运行库由 AZROLES.DLL 提供，它公开了一组供那些利用基于角色的安全的应用程序使用的 COM 接口。管理 UI 是一个 MMC 管理单元，您可以通过运行 AZMAN.MSC 或者通过向您选择的 MMC 控制台中添加授权管理器管理单元对其进行试验。（请注意，管理 UI 与较旧的平台不兼容，因此您将需要使用运行 Windows Server 2003 的计算机来管理 AzMan。）[编辑更新 ― 1/9/2004：Windows Server 2003 管理工具包使您可以在运行 Windows XP Professional 的计算机上安装 Windows Server 2003 管理工具。]
当运行图 1 中显示的 AzMan 管理工具时，您将注意到的第一件事情是它比 COM+ 提供的功能复杂得多。您不再只具有角色和角色分配操作。您现在具有可以分配给任务的低级别操作，而任务随后又可以分配给角色。任务可以包含其他任务，而角色可以包含其他角色。这一分层方法有助于改进目前复杂的应用程序中所需的好像不受限制的角色集。
图 1 管理管理器
以下是任务和角色的创建方式。应用程序设计器定义了被视为安全敏感的整个低级别操作集。然后，该设计器定义了一组映射到这些操作的任务。任务被设计为可由业务分析师理解，因此一个给定任务总是由一个或多个低级别操作组成。如果用户被授予执行某个任务的权限，则他或她就被授予了执行该任务中所有操作的权限。作为一个示例，一个名为“提交采购定单”的任务可能由下列操作组成：获得下一个 PO 编号、将 PO 排队和发送通知。当然，您可以总是简单地将每个任务映射到单个操作，以使事情尽可能保持简单，但是如果您需要的话，则可以利用分隔任务和操作所具有的灵活性。
在定义任务和操作之后，就可以开始编码了，并且无论何时需要执行敏感操作，都可以包含对 AzMan 运行库的调用。该调用是 IAzClientContext.AccessCheck，稍后我将说明一个有关它的用法的示例。
在部署时，应用程序安装程序会设置一个 AzMan 存储区（作为 Active Directory? 的一部分，或者在简单的 XML 文件中），并安装基本的低级别操作和任务。管理员使用 AzMan 管理单元来查看该应用程序的任务的定义和说明。然后，管理员定义对于他/她的组织有意义的角色。就像任务被定义为一组低级别操作一样，角色通常被定义为一组任务。然后，管理员可以向这些角色分配用户和组。实际上，从这时开始，管理员在维护应用程序方面的主要工作将是随着人员加入或离开公司或者更改职衔，在角色中添加和移除用户。
迄今为止，我已经重点介绍了应用程序开发人员和管理员，但是实际上可能存在第三个帮助部署的人 ― 业务逻辑脚本撰写者。每个任务都可以具有关联的脚本。这里的思路是：找到通常通过调用 IsCallerInRole 制定的动态安全决策，将它们移出应用程序代码并移至某个位置，以便管理员无需修改和重新编译代码就可以对应用程序的安全策略进行更改。
示例应用程序：公司库
让我们观察一个示例。假设您要构建一个系统以管理公司图书馆。您需要能够管理书籍库存以及书籍的借阅和归还等等。您将使用 AzMan 实现基于角色的安全。
首先，您需要创建设计中出现的敏感操作列表：
阅读目录
占位（为自己或他人）
借书
还书
将书籍添加到库存
从库存中移除书籍
阅读顾客历史记录（为自己或他人）
请注意，有几个操作对只在运行时才会具有的信息敏感。例如，当试图阅读顾客的历史记录时，应用程序必须提供上下文信息，指示用户是在试图访问他/她自己的历史记录还是他人的历史记录。当建立原型时，可以使用 AzMan 管理单元将这些操作添加到简单的 XML 存储区。图 1 显示了这一添加过程。
如果您要尝试自己继续操作，请运行 AZMAN.MSC，并且通过“Action | Options”菜单确保您处于开发人员模式。在 XML 文件中创建一个新的存储区，然后在该存储区中创建一个新的应用程序。接下来，逐个地添加操作，并且赋予它们名称和代表操作编号的唯一整数。应用程序开发人员使用该编号来标识 AccessCheck 调用中的操作。请注意，在命名操作时，我已经用前缀“op.”对名称进行了编码。这只是为了在稍后创建任务和角色时避免命名冲突，因为这些名称全部来自相同的池并且必须是唯一的。
AzMan 管理单元在两种模式下操作：开发人员和管理员。在管理员模式下，您没有选择创建存储区或应用程序的自由，并且您不能改动应用程序代码所依赖的低级别操作定义。坦白地说，没有什么东西能够妨碍系统管理员进入开发人员模式并完成这些操作，但要点是在管理员模式下，UI 中选项的数量将减少，以简化管理员的工作并帮助他们避免错误。
图 2 AzMan 中的任务定义
下一个步骤是定义一组映射到这些低级别操作的任务，以便管理员能够轻松定义角色。因为您使操作列表保持简单，所以可以为每个操作定义单个任务。除非您绝对需要更高的复杂性，否则有一个保持事情简单的很好的理由，并且它必须与业务逻辑脚本有关 ― 我稍后才会对其进行详细讨论。因此，现在让我们定义一系列基本上与我的操作相同的任务。图 2 显示了在 AzMan 中编辑任务定义时的工作模式。
授权存储区
现在是改变您的身份并假装您是部署应用程序的管理员的时候了。在“Action | Options”菜单下切换到管理员模式，并且注意 GUI 是如何更改的：您不再能够编辑应用程序的低级别操作了。继续操作，并且按照图 3 中的定义为应用程序添加角色。
图 3 角色和任务
在这里，一种简化事情的方式是将角色嵌套。例如，可以根据 Patron 角色定义 Clerk，并且添加“借书”和“还书”任务，如图 4 中所示。请尝试用 COM+ 完成该工作。
图 4 嵌套角色
管理员需要做的最后一件事情是通过向这些抽象角色中添加真实的用户使它们变得具体。为此，请选择“Role Assignments”文件夹，并选择“Assign Roles”操作。请注意，角色只有在被添加到该文件夹之后，才会实际上变为活动角色。例如，IAzApplication.Roles 属性只返回已经添加到 Role Assignments 文件夹中的角色集合，而不是已经定义的所有角色。在分配角色之后，请立即右键单击它以添加 Windows 用户和组，或者添
