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.
Previous
Register
