You can assign Windows users and groups or Authorization Managerspecific groups to Authorization Manager roles. Windows users and groups have a SID and exist in the Windows security database (SAM or AD). Authorization Managerspecific groups (also referred to as application groups) don't have a SID and exist only within the context of an Authorization Manager policy store, application, or application scope. As Figure 3 shows, the Groups container appears at the policy store, application container, and scope levels. (A scope is a subcollection of objects within an application's access control policy.) Two types of application groups exist—basic and LDAP-query. Basic application groups have both a members and a nonmembers attribute. The nonmembers attribute allows exceptions similar to the Deny access control entries (ACEs) exception that you can use on AD and file-system objects. Both the members and nonmembers attributes can contain Windows users and groups and other application groups. LDAP-query application groups can provide dynamic group membership based on an LDAP query that an application can launch against AD at runtime.
You define an Authorization Manager role in terms of operations and tasks. An operation is a low-level procedure that usually makes sense only to the manager of a resource. Operation examples include Read user expense quotum or Write user password. You define operations at the application level and identify them by an operation number (which is an integer).
Tasks are collections of operations that make sense to the administrator of an application. (e.g., Approve expense, Submit expense). You can define tasks at both the application and scope levels.
Authorization Manager supports the creation of a hierarchical role model and thus role inheritance. During role definition, Authorization Manager lets you specify a lower-level role from which a newly created role will inherit all associated tasks and operations.
To make the authorization process more dynamic, Authorization Manager lets you link authorization scripts (or Bizrules, as Microsoft calls them) to tasks. Authorization Manager evaluates Bizrules at runtime to qualify realtime information such as the time of day, currency, or stock values. You can write Bizrules in either VBScript or Jscript, and you store them in the policy store with the other policy information.
You can also use Authorization Manager scopes to fine-tune an application access control policy. A scope can be as simple as a file-system path (for a file-systembased application), an AD container (for an AD-based application), or a URL (for a Web-based application). Figure 3 shows two scopes defined within the Expense Web application: one for treatment of sales department expenses and another for treatment of executive expenses.
Deployment Scenarios
Authorization Manager opens up many new and interesting application deployment scenarios. Let's look at how Authorization Manager can enhance the security of multi-tier applications that use the trusted application architectural model.
Two common architectural models for multi-tier applications are the impersonation/delegation model and trusted application model. Windows 2003 ships with enhancements for both models—most notably, two Kerberos extensions for the impersonation/delegation model: constrained delegation and protocol transition. (For more information about these Kerberos extensions, see "Win.NET Server Kerberos," October 2002, http://www.secadministrator.com, InstantDoc ID 26450.)
In the impersonation/delegation model, the middle-tier application (typically a Web server application) can perform one of the following operations:
- Generate an impersonation token that reflects the user's access control data and use this token to access back-end resources on the user's behalf.
- Forward the user's authentication token to the back-end resource. This process is called delegation and works only when the Kerberos authentication protocol is involved in some way. The use of the Kerberos authentication protocol also enables multi-tier delegation.
The concept behind the impersonation/delegation model is that the user identity survives beyond the middle tier, letting access control settings on back-end resources be set using the user identity. In the trusted application model, the user's identity doesn't survive beyond the middle tier. The trusted application model uses the Web server's or Web application's service account for all access to back-end resources.
Integrating Authorization Manager into the trusted application model lets you do granular role-based access control enforcement and fine-grain runtime auditing at the Web application level. But the integration doesn't remove the trusted application model's classic advantages, such as
- easier access control management on back-end resource and application servers. You can use one account (the Web server or Web application's service account) to configure all access control settings.
- support for connection pooling. Connection pooling provides a higher level of scalability, but it makes sense only if all connections to the back-end infrastructure run in the same user security context. Connection pooling doesn't add much value to the impersonation/delegation model because every connection runs in another user's security context (the context of the impersonated or delegated user).
- a controlled access point. In the trusted application model, all user access to back-end resources occurs through the Web front end. Users can't use any other channel to access back-end resources (provided that the appropriate ACLs are in place on the back-end resources).
Web Figure 1 (http://www.secadministrator.com, InstantDoc ID 38775) shows the difference between the impersonation/delegation model and the trusted model with Authorization Manager.
Authorization Manager and RBAC Roadmap
Windows 2003 lets you use Authorization Manager and its RBAC model to role-enable LOB applications. With the exception of Microsoft Internet Information Services (IIS) 6.0's URL-based authorization feature, Microsoft doesn't yet provide applications that are role-enabled out of the box, so right now, Authorization Manager is more helpful for developers than for administrators. However, things might change in the years to come. Until then, you can use software such as Quest Software's FastLane ActiveRoles to role-enable AD management and other tasks. FastLane ActiveRoles provides support for an RBAC model on top of the DAC model. You can read more about this software at http://www.quest.com/fastlane/activeroles.