Role-Based Access Control for Multi-tier Applications Using Authorization Manager
Applies To: Windows Server 2003 with SP1
Author: Dave McPherson, Microsoft Corporation
Acknowledgements: Thanks to Jason Rush, Praerit Garg, Don Schmidt, Paul Leach, and Doug Bayer for their support.
In the Windows Server 2003 family, Authorization Manager introduces a new model for application authorization on the Windows platform. Authorization Manager provides an easy-to-use authorization framework for line-of-business applications where you must grant access to users according to the users role within an organization or application. To address this need, applications often create custom implementations of authorization mechanisms, which increases development costs and administrative complexity because of divergent authorization models. Authorization Manager gives applications a role-based access control framework that provides manageable administration and natural development for Web-based or line-of-business applications.
In This White Paper
Developing Authorization Manager Applications
Environment-specific Design Issues
Internet Information Services 6.0 URL Authorization
Scenario: Web Expense Application
Scenario: Using Authorization Manager with Custom Principals
ACLs and line-of-business applications
Windows operating systems have supported the use of ACLs in access control for applications since the introduction of the Private Object Security API in Microsoft Windows NT Server 4.0. In the ACL model, you can attach discretionary access control lists (DACLs) to a securable object and you make access decisions by calling the AccessCheck application programming interface (API), which looks at a users group memberships in a token and compares them to the contents of the ACL to determine if the user has the requested access. The ACL model is ideal for many types of applications. Resource managers that have well-defined persistent objects, such as the NT system registry, use the ACL model appropriately to provide object-level access control. In these types of applications, access control decisions can always be made in terms of a user requesting access to an existing object. In the future, applications that use the ACL model should use AuthzAPI, which was introduced in Windows XP and the Windows Server 2003 family. It provides performance and flexibility enhancements, compared to the Windows NT Private Object Security APIs. For more information about AuthzAPI, see the Microsoft Platform Software Development Kit.
A distinct authorization problem exists for some line-of-business (LOB) applications, such as a Web expense reporting application or a shopping application. For these applications, the authorization decisions do not determine access to well-defined persistent objects. Instead, they verify a workflow or perform multiple distinct operations, such as querying a database and sending mail. In LOB applications, access decisions are often made on business logic, such as the amount submitted in an expense application or verification of workflow completion, and not just based on token group membership. Applications that don't have well-defined persistent objects have no place to put an ACL, so the ACL model can be harder to apply in these applications.
Role-based access control
Traditional access control administration models are based on objects. In these models, access control is specified at the object or object container (for example, in an ACL), and the administrator must go to the object to query and specify access to the object. These models require administrators to translate the organizational authorization policy into permissions on objects: Each object has a list of access permissions that is granted to various users and groups within an organization. Role-based access control (RBAC) simplifies access control administration and provides better manageability in enterprise environments by allowing permissions to be managed in terms of user job roles.
Some of the goals of role-based access control can be accomplished using groups. A group corresponds to an employee role, and application administrators can specify the permissions that are needed by the role by granting the group permission in a DACL for the object. As object collections grow, the number of places where administrators need to manage permissions grows. Diligent use of resource groups and user groups can help minimize this effort, but this requires consistent practice and coordination among administrators and precise definitions of resource groups. These processes slow down the administrative process, so administrators often avoid them.
Additionally, querying the granted access to a particular group or role across an application becomes more difficult as the number of objects grows. To accurately determine what permissions are granted to a user or group, administrators have to examine the permissions on every object. While inheritance appears to simplify this, the ability of each object to avoid inheriting permissions still makes it necessary to look at each object to fully understand the authorization policy. Since there are too many objects to query, the state of access control with respect to a particular group or user is sometimes rarely verified.
Role-based access control attempts to allow administrators to specify access control in terms of the organizational structure of a company. RBAC does this by creating a new object called a role. You assign a user to a role to perform a job function. Unlike groups, however, a role defines the authorization permissions on some set of resources. In the RBAC model, the administrator uses the role to manage permissions and assignments. For example, a company may create a role called Sales Manager that has the permissions that a sales manager needs for their job. When sales managers are hired, they are assigned the Sales Manager role and instantly have all required permissions for that job. When they leave the position of sales manager, they are removed from the Sales Manager role and no longer have Sales Manager access. Since the role allows access to be granted in terms of a company's organizational model, it is more intuitive and natural for administrators to specify access control. Figure 1 identifies the relationship between the role, the users, and the permissions. In this model, the role is the object to which permissions are granted, and the users are assigned to the role.
Figure 1: Role-based access
.gif "Art Image")
RBAC maps user job roles to application permissions so that access control administration can be accomplished in terms of a users job role. The RBAC system translates a users role membership to application permissions. Since the permissions are granted at the role, permissions can be queried and changed at the role without examining the specific resources. In most environments, once the role permissions are established, changes to a roles permissions will be rare, compared to changes in assignments to the role. This means that administrators will have to set up roles, such as Employee, Manager and Administrator, but once roles are created, administrators will manage membership in the roles; not permissions on objects.
Authorization Manager conceptual model
Authorization Manager is a set of COM-based runtime interfaces that allows applications to easily manage and verify a clients requests to perform application operations. Additionally, Authorization Manager provides a Microsoft Management Console (MMC) snap-in that application administrators can use to manage user roles and permissions.
Authorization Manager:
Simplifies application access control administration in line-of-business applications.
Provides a simplified and natural development model.
Enables flexible and dynamic authorization decisions.
Typically, you define access control models with the terms Subject, Resources, and Permissions. A subject is often a user operating upon resources. Access is controlled by a set of permissions that allow the subject to perform specific operations on the resource. Administration of access control rarely deals directly with these constructs but more often involves management of collections of subjects, resources, and permissions. You usually manage subjects or users in groups, but you manage resources in application-specific collections, such as directories or organizational units. Permissions may be granted directly, but are often grouped into higher level permissions such as Full Control. These collections make authorization management possible in environments where there are many subjects, resources, or permissions. Application administrators must use these collections to make an authorization policy for the application so that each subject has the appropriate permissions to use the application resources.
Traditional resource manager applications store authorization policy with the resources that the policy applies to. For example, an ACL on a file is stored by the resource manager and is logically associated with the file. In the Authorization Manager model, authorization policy data is stored separately from the object in an authorization policy store. An application identifies the operations or tasks that the application can perform and declares them in the authorization store when the application is installed. Administrators manage the authorization policy by defining roles in terms of the tasks and operations that are needed to perform a job in an organization. The definitions of roles, tasks and operations, and the assignment of users and groups to the roles are all stored in the authorization store. Applications query the authorization policy at run time to confirm that a client is authorized to perform a requested operation on a resource. Authorization Manager provides APIs for managing authorization policy and validating access control and a user interface for administrators so that they can manage the authorization policy store. The following figure illustrates the composition of the authorization store that Authorization Manager provides for querying applications and managing the authorization store. It also illustrates the relationships between each Authorization Manager object.
Figure 2: Authorization Manager object relationships
.gif "Art Image")
Definitions
This section introduces the objects that Authorization Manager uses to manage authorization policy.
Operation. A low-level permission that a resource manager uses to identify security procedures. Several operations may be required to perform a meaningful task. Operations are often not exposed or meaningful to administrators. An example of an operation could be WriteAttributes or ReadAttributes.
Task. A collection of low-level operations. The purpose of the task is to determine which low-level operations are required to do some unit of work that is meaningful to administrators. An example of a task might be Change Password. Tasks can also contain other tasks. For example, a task called Manage User Accounts may include the tasks Change Password, Reset Password, Disable Account, and so on.
Role Definitions. A collection of permissions that are needed for a particular role, where permissions can be tasks or operations. Notice that this definition is similar to that of a task.
Role. The set of permissions that users must have to be able to do their job. The role is applied to a set of objects and users are assigned to the role.
BizRules. Also called authorization scripts. Scripts that are attached to a task object that is run at the time of the access request. It can use information that is only available at runtime, such as "time of day" or "dollar amount requested," to make an authentication decision.
Scope. A collection of objects or resources with a distinct authorization policy. A scope can represent a physical collection, such as a folder, or a more flexible collection of resources, such as *.doc. Applications can use the scope as necessary to group resources, and must be able to map the requested resource to its scope at the time the application checks the access for a user.
Application groups. Groups that are applicable only to an authorization store, an application within an authorization store, or a scope within an application. Authorization Manager implements two types of application groups.
Application basic groups. A subset of application groups. A list of members (Active Directory Users or groups or other application groups) that is maintained for a specific set of applications, a single application, or a scope within an application. Application groups also can identify non-members, which allows for exceptions where a large group can be used with a smaller group or particular user excluded.
LDAP-query groups. A subset of application groups. Groups that are defined by an Lightweight Directory Access Protocol (LDAP) query on a given Active Directory users account attributes. These provide flexible group membership to be defined in terms of user account attributes and that remains up to date with the users account object.