You can store Authorization Manager's centralized access policy database either in AD or in an XML file. To use AD as the access control policy store, it must be at the native Windows 2003 functionality level. AD is a better choice than an XML file because AD lets you delegate the administration of your access control policy subcomponents (e.g., authorization stores, applications, scopes—all of which I explain later) to other administrators. AD-based authorization stores are by default stored in the Program Data container in the AD domain naming context (NC). As a consequence, the stores are replicated to every domain controller (DC) in a domain.
The primary administration interface to the Authorization Manager is the MMC Authorization Manager snap-in, which Figure 2 shows. The Authorization Manager console supports two modes: developer mode and administrator mode. In the more restricted administrator mode, users can do everything developers can do except create new authorization stores, applications, or operations and change operations, application names, or version information. To switch between modes, click Action, Options in the Authorization Manager console.
Perhaps the most important aspect of Microsoft's implementation of the RBAC model is that it allows flexible and dynamic access control decisions. Administrators can apply an application's access control policy to application-specific objects or operations (e.g., sending an email message, approving an expense). In the DAC model, you use predefined access control permissions to apply access control policy to specific objects, such as file-system objects, registry objects, and database objects.
The following Authorization Manager features let you easily change the access control decision-making behavior at runtime:
- Authorization Manager supports dynamic groups whose membership can change depending on the outcome of a Lightweight Directory Access Protocol (LDAP) query that an application launches at runtime. A role-enabled customer relationship management (CRM) application could, for example, automatically send an email message to members of a dynamic Customer group. You can base Customer group membership on the outcome of a realtime LDAP query that an application launches against a directory holding your customer data.
- Authorization Manager supports authorization scripts that execute at runtime and that link access control decisions to realtime data such as time of day, currency, and stock values. An e-commerce application could, for example, block the ordering of particular products during a certain period of the day or year (e.g., an application might allow access to the Christmas trees section in the product catalog during the month of December only).
- Authorization Manager also supports fine-grain runtime auditing. Authorization Manager conducts pass/fail audits on application initialization, client context initialization and deletion, and all access checks. Administrators can also use store-level auditing on the policy store in AD or in an XML file.
These features make Authorization Manager's access control model well suited for line of business (LOB) applications, such as the CRM or e-commerce applications I mentioned earlier. In such applications, access control decisions often depend on specific business logic, which might involve special operations or the execution of workflow logic. LOB applications might include querying a directory or waiting for a manager's email message approval. In contrast, the DAC model makes access control decisions based solely on group memberships and user rights contained in users' access tokens.
Authorization Manager Concepts
The Authorization Manager's authorization policy store comprises one or more collections of the following object types: applications, groups, roles, tasks, scopes, and Bizrules. The policy store can contain access control policies for multiple applications. For example, Figure 3 shows a policy store that contains a Web-based expense application and a Web-based customer lead application.
Register
