Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)

Authorization Manager is a fundamental shift In Microsoft’s way of dealing with access control enforcement and management. In the long run it will affect everyone (including architects, administrators, and developers) who is dealing with the new generation of Microsoft enterprise operating systems and the applications that are running on top of these platforms. The Authorization Manager is all about Microsoft’s efforts to introduce a role- based access control model (RBAC) for applications running on top of the Windows platform.

In Windows Server 2003 Authorization Manager and its role-based access control model can be used to role-enable LOB applications. An interesting combination is using Authorization Manager together with IIS 6.0’s URL- based authorization feature. So far, MS does not provide applications that are out-of-the-box role-enabled—and in that sense at the time of writing Authorization Manager is mainly developer-focused. In the years to come MS may however natively RBAC-enable other Windows applications.

12.1.1 Introducing RBAC

The concepts behind the role-based authorization model (RBAC) were created by David Ferraiolo and Richard Kuhn of the U.S. National Institute of Standards and Technology (NIST). They introduced the concept of role- based access control to the IT world in 1992 in their paper entitled “Role- Based Access Controls.”

Until 1992, most platforms and applications supported either a mandatory access control model (MAC) or a discretionary access control model (DAC). These two models are specified in the U.S. Department of Defense (DoD) Trusted Computer Security Evaluation Criteria (TCSEC) that was published in 1985. Of the two, DAC is certainly the most commonly used model. It is used in many commercial OSs, including Microsoft Windows NT and Windows 2000.

In the DAC model, granting and revoking of access privileges to a resource are left to the discretion of the individual users. DAC allows users to grant or revoke access to any of the objects under their direct control (in Windows terms, objects or resources that the user owns) without the inter- cession of a system administrator. As such, DAC proposes a highly decentralized approach to access control management.

On the other end of the spectrum is the MAC model. MAC proposes a highly centralized access control model where a central authority grants or denies user access to resources. In the MAC model the central authority typically performs the following two key tasks:

1. It gives users a clearance level (a process that is also known as granting membership or clearing users).

2. It labels the resources with an access level for the different clearance levels (a process that is also known as associating operational sensitivities to resources).

Central control is usually very well applicable to military and government organizations. In such environments the primary concern is to prohibit the unauthorized flow of information from a higher level to a lower level in the organization.

Now that we have an idea what the MAC and DAC models are about, let’s look at what the RBAC model means. In what follows I will only focus on the differences between the DAC and the RBAC models. This is simply because DAC is the model used in NT, and Microsoft so far has not provided any commercial-off-the-shelf (COTS) support for the MAC model.

As mentioned earlier, RBAC stands for role-based access control. In the RBAC model, everything centers on the organizational role of a user. Access to resources is based on the role that individual users take as part of an organization. The definition of a role takes into account the specification of an individual user’s duties, responsibilities, and qualifications.

In the DAC model, access control management and enforcement is very object- and resource-centric. From an administrative point of view, it is more natural to manage access control in a role-based fashion, which is why the DAC model creates the overhead for an administrator to translate the organizational model—based on users’ roles—into the object-centric model—based on access rights to resources. The role concept in the RBAC model can be thought of as a special type of access control group. Anyone familiar with NT should know the concept of a group. A role is a special group that is linked to a set of tasks that a user or a set of users can perform in the context of a particular organization and the applications that are defined in that organization. A role is also fundamentally different from a group. This is explained in the next sections and in Figure 12.1.

Figure 12.1: Comparing the DAC and the RBAC models.

The key difference between a role and a group is that groups as we know them from the DAC model are only used to facilitate access control management on the resource level. They group users and take away the administrative burden to define and maintain access control for every individual user. A role, on the contrary, directly implies a set of resource access permissions. These permissions are based on the role definition or the role to task/ operation mappings that are stored in the RBAC access control policy database. To know what tasks or operations a user is allowed to perform, it is sufficient to know his or her role. Unlike in the DAC model, there is no more need to query the access permissions of the different resources at the time of access.

Another important difference with the DAC model is the notion of centralized access control validation and enforcement in the RBAC model. In the RBAC model, role-enabled applications query the RBAC policy database or the associated access control authority to find out whether a user is allowed to perform a particular action or not. In the DAC model, access control enforcement and validation is completely decentralized and occurs on the DAC-enabled application or resource level. In NT, for example, a local machine entity known as the security reference monitor (SRM) is responsible for comparing the content of a user’s access token to the entries in an Access Control List (ACL) on a resource and deciding whether a user is allowed access or not.

The reason why centralization is so attractive when it comes to access control enforcement is the following: In most organizations, resource and information security objectives support a security policy. The latter is usually defined at the highest level of the organization. To support such policies, a capability to centrally control and maintain access rights is required (or at least highly recommended).

It can also be argued that the RBAC model in general better maps to the administrative model used for resource and application access control management that is used in most organizations:

• The security administrator is responsible for enforcing the access control policy in a centralized way. Contrary to the DAC model, in the RBAC model a user cannot simply pass his or her access permissions onto other users at his or her discretion.

• The administrators managing people are responsible for adding users to roles. To facilitate role management, they can create user groups. This time groups are not used to facilitate ACL management (as in the DAC model), but to facilitate role management.

• Resource and application administrators define what a given role can do in terms of application and resource operations and tasks. They pass this information to the security administrator. The latter makes sure the appropriate role-to-operation/task mappings are stored in the access control policy database. As opposed to the DAC model, resource and application administrators should not bother about setting the appropriate ACLs on every individual resource anymore.

Table 12.1 summarizes the major differences between the DAC and RBAC models.

12.1.2 Windows Server 2003 RBAC architecture

Before digging into the Windows Server 2003 RBAC architecture, it must be said that role-based access control is not entirely new to Microsoft OSs and applications:

• The concept of user and resource “groups” that has been around since the early days of Windows NT provide role-like functionality. Nevertheless, as explained earlier, NT groups are fundamentally different from RBAC roles.

• The COM development framework also has the notion of an application-specific role. This role is very similar to the one used in the context of the Windows Server 2003 RBAC model. The key difference with RBAC roles is that COM roles can only be used in applications written using the COM and COM+ development frameworks. The Windows Server 2003 RBAC model is independent of the development framework.

It is also important to stress that the new RBAC model introduced in Windows Server 2003 will not replace all DAC models that are currently in place on the Windows platform. The two models can easily coexist. Later on, Microsoft may integrate some of the applications’ DAC models into the RBAC model or even fully move applications to a RBAC model. Figure12.2 shows the current Windows Server 2003 RBAC architecture and its major components.

Figure 12.2: Authorization Manager architecture overview.

At the center of the RBAC architecture sits the Authorization Manager. The Authorization Manager is the management and decision-making engine of the RBAC system.

The authorization manager makes sure all RBAC information is prop- erly stored in the policy database. It also provides access points to the database for applications to query the authorization policy and for administrators to manage the authorization policy.

RBAC-enabled applications query the Authorization Manager at run time to find out whether a particular user is allowed to perform a certain application-level operation or not. The Authorization Manager gives a go/ no-go based on the role membership of the user and the application opera- tion/task-to-role mapping information that is stored in the policy database. Remember that this is a fundamental change compared to the DAC model: In this model the local resource manager on the host machine makes the access control decision. RBAC-enabled applications access the authorization manager and its functions through a set of COM-based run-time interfaces. These are commonly referred to as the Authorization API (or, as its abbreviation, AuthzAPI).

The Authorization Manager’s centralized access policy database can be kept either in Active Directory or in an XML file. To use AD as the access control policy store, your AD domain should be in the native Windows Server 2003 functionality level. The advantage of using AD over an XML file for storage is that you can delegate the administration of subcomponents (authorization stores, applications, and scopes—these concepts are explained later) of your access control policy to different administrators.

AD-based Authorization Stores are by default stored in the “Program Data” container in the AD domain naming context. As a consequence, they are replicated to every domain controller (DC) in a domain.

The primary administration interface to the authorization manager is an MMC snap-in called azman.msc, which is illustrated in Figure 12.3. In the next section I use this interface to explain the Authorization Manager’s conceptual model. The snap-in supports two modes: developer mode and administrator mode. The most restricted mode is administrator mode: In this mode users can do everything except create new authorization stores, applications, or operations, and change operations, application names, or version information (these concepts are explained later). To switch between modes, use the Action\Options… menu option.

Figure 12.3: Authorization Manager MMC snap-in (azman.msc).

Perhaps the most important feature of Microsoft’s implementation of the RBAC model is that it allows for highly flexible and dynamic access control decisions.

• The access control policy can be easily applied to application-specific objects or operations (e.g., “send a mail,” “approve an expense”). The latter is a key differentiator with Microsoft’s implementation of the DAC model: This model was tailored to be applied to specific objects, such as file system objects, registry objects, and database objects.

• Thanks to the following Authorization Manager features, the access control decision-making behavior can easily be changed at run time:

• Authorization Manager supports dynamic groups whose member- ship can change depending on the outcome of an LDAP query that is launched at run time.

• Authorization Manager supports authorization scripts that are executed at run time and that can be used to link access control decisions to real-time data such as the time of day, currency, and stock values.

I will come back to both dynamic groups and authorization scripts in Section 12.1.3.

Authorization Manager also supports fine-grain run-time auditing. Authorization Manager audits application initialization, client context initialization and deletion, and all access checks with pass and fail audits. Obviously, administrators can also use store-level auditing: on the AD objects (if the AD is used as policy store) and on the file-system level (if an XML file is used as policy store).

All of the this makes the Authorization Manager’s access control model very well suited for line of business (LOB) applications. In such applications, access control decisions often depend on specific business logic. The latter may involve special operations or even the execution of a piece of workflow logic: Examples are querying a directory, waiting for a mail approval to come back from a manager, or querying a Web service for a currency or stock value. This richness is very distinct from the limited access control decision logic that is available in Microsoft’s classical DAC model. In this model, access control decisions are simply based on the group memberships and user rights contained in users’ access tokens.

12.1.3 Authorization Manager concepts

The Authorization Manager’s Authorization Policy Store is made up of one or more collections of the following object types: applications, groups, roles, tasks, scopes, and bizrules. These concepts are illustrated in Figure12.4 and explained next.

Figure 12.4: Authorization Manager concepts.

The policy store can contain the access control policies of multiple applications. In the example in Figure 12.4, it contains the access control policy for a Web-based expense application and a Web-based customer lead application. In the following examples, I will look in more detail at the access control policy elements of the Web-based expense application.

To assign users to role definitions, Authorization Manager can use Windows users and groups or Authorization Manager–specific groups. Windows users and groups have a Security Identity (SID) and exist in the Windows security database (AD). Authorization Manager–specific groups (these are also referred to as “application groups”) do not have an SID and only exist within the context of an Authorization Manager Policy Store, application, or application scope. As you can see in Figure 12.4, the Groups container appears on the policy store, application container, and scope levels. There are two types of Authorization Manager–specific application groups:

1. Basic application groups have the unique property that they have both a members attribute and a nonmembers attribute. The latter allows for exceptions similar to the deny ACEs used on AD and file system objects. Both attributes can contain Windows users and groups and other Authorization Manager application groups.

2. LDAP-query application groups have the unique property that they can provide dynamic group membership. The latter is based on an LDAP-query that is launched against AD at run time.

An Authorization Manager role is defined in terms of tasks and operations:

• An operation is a low-level operation that usually only makes sense to the manager of a resource. Examples are “read user expense quotum” or “write user password.” Operations can only be defined at the application level and are always identified by an operation number (which is an integer).

• Tasks are collections of operations that do make sense to the administrator of an application. Examples are “Approve Expense” or “Submit Expense.” Tasks can be defined at both the application and the scope levels.

Authorization Manager supports the creation of a hierarchical role model and thus role inheritance. During the definition of a role, Authorization Manager allows for the specification of a lower-level role from which the newly created role will inherit all associated tasks and operations.

As mentioned earlier, to make the authorization process more dynamic, Authorization Manager allows for linking authorization scripts (or Bizrules, as Microsoft calls them) to tasks. Just like the LDAP queries behind dynamic application groups, Bizrules are evaluated at run time to qualify real-time information such as the time of day, currency, or stock values. They can be written in either VBscript or Jscript and are stored in the policy store along with all the other policy information.

An application access control policy can also be fine-tuned using Authorization Manager scopes. A scope is a subcollection of objects within an application’s 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). In the example of Figure 12.4, I defined two additional scopes within the Expense Web application: one for the treatment of the sales department expenses and another for the executive expenses.

12.1.4 Authorization Manager deployment scenarios

Authorization Manager opens up many new, interesting application deployment scenarios. In what follows, we look at how Authorization Manager can enhance the security quality of multitier applications that are using the trusted application architectural model.

Two commonly used architectural models for multitier applications are the impersonation/delegation and trusted application models. The differences between the two models are summarized next. Windows Server 2003 comes with enhancements for both models. An interesting change enhancing the impersonation/delegation model are these Kerberos extensions coming with Windows Server 2003: constrained delegation and protocol transition (explained in Chapter 5).

In the impersonation/delegation model, the middle-tier application (typically a Web server application) can do one of the following:

• 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. The latter is called delegation and only works when the Kerberos authentication protocol is involved in one way or another. The use of the Kerberos authentication protocol also enables multitier delegation.

The basic idea behind the impersonation/delegation model is that the user identity survives beyond the middle tier. Doing so, access control settings on back-end resources can be set using the user identity.

In the trusted application model, the user’s identity does not survive beyond the middle tier. In the trusted application model, all access to back-end resources is done using the Web server or Web application’s service account. The difference between the two models is illustrated in Figure 12.5.

Figure 12.5: Impersonation/delegation versus trusted application model.

Integrating Authorization Manager into the trusted application model has the following advantages:

• It adds the capability to perform very granular role-based access control enforcement at the Web application level.

• It provides fine-grain run-time auditing capabilities at the Web application level.

In addition to these two key advantages brought by Authorization Manager, the trusted application model obviously keeps its classic advantages:

• Easier access control management on the back-end resource/application servers. All access control settings can be set using a single account: the Web server or Web application’s service account.

• Support for connection pooling provides a higher level of scalability. Connection pooling only makes sense if all connections to the back-end infrastructure run in the same user security context. Connection pooling does not add a lot of value when the impersonation/delegation model is used because every connection runs in another user’s security context (the context of the impersonated or delegated user).

• Provides a controlled access point. In the trusted application model, all user access to back-end resources occurs using the Web front end. There is no way for users to access the back-end resources using some other channel bypassing the Web front end (on the condition that the appropriate ACLs are in place on the back-end resources).