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:
- The security administrator is responsible for centrally enforcing access control policy. In the RBAC model, users can't simply pass their access permissions to other users at their discretion, as users in the DAC model can.
- Administrators who manage people are responsible for adding users to roles and often create user groups to facilitate role management. In the RBAC model, groups facilitate role management; in the DAC model, groups facilitate ACL management.
- In the RBAC model, resource and application administrators define roles in terms of application and resource operations and tasks. They pass this information to the security administrator, who ensures that the appropriate role-to-operation or role-to-task mappings are stored in the access control policy database. Administrators don't need to set appropriate ACLs on individual resources as they do in the DAC model.
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).
Register
