Role-Based Access Control

If you've played around with Windows Server 2003, you've probably encountered the new Active Directory (AD) Microsoft Management Console (MMC) Authorization Manager snap-in that Microsoft introduced in Release Candidate 1 (RC1). Authorization Manager is Microsoft's effort to introduce a role-based access control (RBAC) model for applications that run on the Windows platform. David Ferraiolo and Richard Kuhn of the National Institute of Standards and Technology (NIST) first introduced the concept of RBAC in 1992 in the paper "Role-Based Access Controls," which you can download from http://hissa.ncsl.nist.gov/rbac/paper/rbac1.html. After I explain the main concepts of the RBAC model and how it differs from other access control models, I detail how Microsoft has used Authorization Manager to implement the RBAC model.

The RBAC Model
Before 1992, most platforms and applications supported either a mandatory access control (MAC) model or a discretionary access control (DAC) model. The two models are specified in the Trusted Computer Security Evaluation Criteria (TCSEC) that the US Department of Defense (DoD) published in 1985. Of the two, the DAC model is more common—and used in many commercial OSs, including Windows 2000 Server and Windows NT.

In the DAC model, managing access privileges to resources is left to the discretion of individual users. This decentralized approach lets users grant or revoke access to any object under their direct control (i.e, objects or resources the user owns) without systems administrator intercession.

The MAC model is a highly centralized access control approach in which a central authority grants or denies user access to resources. The central authority gives individuals a clearance level and labels resources with an access level for the different clearance levels. Environments in which the primary concern is to prohibit unauthorized information flow from a higher level in the organization to a lower level (e.g., military organizations) often use this type of centralized access control. Because Microsoft hasn't yet provided any Commercial Off-the-Shelf (COTS) support for the MAC model, I limit my discussion to comparing the RBAC model with the DAC model. Table 1, page 2, summarizes the differences between the DAC and RBAC models.

The key component of the RBAC model is a user's organizational role, which defines his or her duties, responsibilities, and qualifications. In contrast, the DAC model is object- and resource-centric. From an administrative point of view, managing access control directly in a role-based fashion is more natural; translating the organizational model (based on users' roles) into the object-centric model (based on access rights to resources), as an administrator does in the DAC model, is more difficult.

The RBAC model is a special type of access control group that links to a set of tasks that a user or a set of users can perform in the context of a particular organization. However, a role is also fundamentally different from a group. Groups, as we know them from the DAC model, facilitate access control management at the resource level by letting you define and maintain access control for groups rather than for individual users. A role, on the contrary, implies a set of resource access permissions that are based on role definitions (i.e., role-to-task and role-to-operation mappings stored in the RBAC access control policy database). To determine the tasks or operations that a user has permission to perform, you need know only the user's role; you don't need to query the access permissions of the different resources at the time of access, as you do in the DAC model.

Access control validation and enforcement is another area in which the RBAC model differs from the DAC model. In the RBAC model, role-enabled applications query the RBAC policy database or the associated access control authority to determine whether a user has permission to perform a particular action. The DAC model's decentralized access control enforcement and validation occurs at the DAC-enabled application or resource level. In NT, for example, a local machine entity known as the security reference monitor (SRM) compares the content of a user's access token with a resource's ACL entries to determine whether a user has access.

Centralized access control enforcement is attractive because in most organizations, resource and information security objectives support a security policy that's typically defined at the highest level of the organization. Supporting such policies requires the ability to centrally control and maintain access rights. You can also argue that, for the following reasons, the RBAC model maps better to the administrative model that most organizations use for resource and application access control management:

A good example of an application that could easily take advantage of an RBAC model is an expense claiming and approval application. In such an application, you typically define a user and an approver role. Members of the user role have permission to create expense entries in the expense database. Every user has a manager attribute that links him or her to the expense approver. Members of the manager role are only permitted to change the status attribute of expense resources that are linked to users they manage.

Windows 2003 RBAC Architecture
Before digging into the Windows 2003 RBAC architecture, let me point out that RBAC isn't entirely new to Microsoft OSs and applications. For example, the concept of user and resource groups that has been around since early NT days provides rolelike functionality. Also, the COM development framework uses the concept of an application-specific role that's similar to the one that the Windows 2003 RBAC model uses. The key difference is that you can use COM roles only in applications that you use the COM and COM+ development frameworks to write. The Windows 2003 RBAC model is independent of the development framework, so you can choose to use COM, COM+, or the Windows .NET Framework.

Note also that the RBAC model introduced in Windows 2003 won't replace all the DAC models currently in place in Windows applications—at least not right away. RBAC and DAC can easily coexist. However, at some point, Microsoft might integrate some of the DAC models into the RBAC model or even fully move applications to an RBAC model.

Figure 1 shows the current Windows 2003 RBAC architecture and its major components. Authorization Manager is the management and decision-making engine of the RBAC system. It makes sure all RBAC information is properly stored in the policy database and lets applications query and administrators manage authorization policies in the database.

RBAC-enabled applications query Authorization Manager at runtime to find out whether a particular user has rights to perform a certain application-level operation. Authorization Manager gives permission to proceed with the operation based on the role membership of the user and the application operation-to-role or task-to-role mapping information that's stored in the policy database. In the DAC model, the local resource manager on the host machine makes the access control decision. RBAC-enabled applications access Authorization Manager and its functions through a set of COM-based runtime interfaces, referred to as the Authorization API (AuthzAPI).

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:

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.

You can assign Windows users and groups or Authorization Manager­specific groups to Authorization Manager roles. Windows users and groups have a SID and exist in the Windows security database (SAM or AD). Authorization Manager­specific 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-system­based 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:

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

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.