Motivation for a New Model of Authorization

In a metacomputing environment, an application may acquire and utilize heterogeneous resources such as hosts, databases, scientific data sources, auxiliary devices (e.g. printers) and computer-controlled scientific instruments. Different access rights are defined for various resources, for instance access modes for a host may include checking the load status of the host and loading a job, while access rights for a scientific instrument may include monitoring and setting various parameters.

Our design goal is to support authorization for different kinds of resources in a uniform manner. The type of the protected resource is opaque to the authorization model, as compared with the CRISIS architecture [7], which provides ACLs where types of access are related to the type of protected resource. A file ACL lists principals allowed read, write or execute access to the file. A node ACL contains principals allowed to run jobs on this node. This approach requires code to recognize the type of protected object. Addition of new types of resources will require modifications to the existing code.

Metacomputing systems cover large networks connecting multiple research, education, government and commercial organizations. These organizations represent different administrative domains and administrators impose domain-specific security policies.

Figure 2 Multipolicy environment example

Consider the following scenario shown in Figure 2. A user logs onto a machine residing in domain A and wants to perform some computation on a remote machine residing in security domain B. Let us identify the security issues to be considered:

1) Establishing a trust relationship by means of authentication of the entities between security domains.

2) Defining fine-grained access control and authorization policies to protect client resources.

In a wide area network, it is unlikely that sites would make their resources available to others if there are no means of protection. There must be a flexible mechanism to represent user-defined security policies, such as:

• type and amount of resources that the node is willing to allocate, e.g. memory, processors, terminal access, access to the local files and directories, network connections

• applications that can be run on the node, e.g. name of application, version, platform, endorser

• time periods for which access is granted, e.g. time of day or day of the week

• requirement of payment for the resources consumed

Domain administrators will define domain-specific policies as well as mandatory policies which must not be overridden by users, such as:

• authentication mechanism or set of suitable mechanisms, used to authenticate a user

• location, authorization is granted to users residing in specific hosts or domains

• attributes of users that must be possessed by users in order to get access to resource, e.g. level of competence, see Section 7

3) Specification of access policies for entities from multiple administrative domains poses additional problems:

• There are multiple mechanisms for authentication of users in different domains. Therefore, there may be no single syntax for specification of principals. For example, an application may use Kerberos V5 [3] as an authentication service. Kerberos V5 provides secret-key based authentication and format of the Kerberos V5 principal name is user_name/instance@REALM. Other domains may use DCE to obtain user's identity credentials. In most implementations, principals are identified by User ID and groups are identified by Group ID. Another domain might use client authentication in SSL based on public-key cryptography. Principals are identified by a global name, syntactically tied to the X.500 directory.

• Similarly there may be no standard for security policy representation. Administrators of each domain might use domain-specific policy syntax and heterogeneous implementations of the policies.

• In a multipolicy environment the policy integration should incorporate diverse authorization models, which can coexist in distributed system, such as Access Control Lists, capabilities and lattice-based policies.

4) Discovering policies associated with the targeted resource. The assumption that all relevant credentials are passed for evaluation contradicts privacy requirements. It might be desirable to reveal only required group memberships and user attributes.

5) Access control decisions are made locally by the owner of the resource. This will require integration of different sets of policies associated with the domain providing resources, the domain requesting resources and individual users within each domain. In the example illustrated in Figure 2 the request to load an application will be granted if all depicted policies are met.

6) Enforcement of the security policies. There should be a mechanism for monitoring execution of the program on a particular node to ensure that the program keeps strictly to the limits imposed by the local administrators.

This paper describes an authorization framework designed to meet these needs. Our framework is usable for a wide range of systems and applications. It includes a flexible mechanism for security policy representation and provides the integration of local and distributed security policies. The system supports the common authorization requirements but provides the means for defining and integrating application or organization specific policies as well.