Generic Authorization and Access-control API(GAA-API)

The GAA-API provides a general-purpose execution environment in which EACLs are evaluated. Next we provide a brief description of the main GAA-API functions.

The 25#25 function is called to obtain the security policy associated with the object. It takes the target object and authorization database as input and returns an ordered list of EACLs.

The application maintains authorization information in a form understood by the application. It can be stored in a file, database, and directory service or in some other way. The application-specific callback function provided for the GAA-API retrieves the policy information and translates it into the internal representation understood by the GAA-API. Currently the policy is written at the object level, the call-back function must collect all the per object policies and order them by priority. How the policies are stored and retrieved is opaque to the GAA-API and is not reflected in the EACL.

The resulting policy that is passed to the GAA-API for evaluation represents the combination of several policies possibly from different domains and individual users of the system. The specific mechanism for retrieving the policies is passed as a call-back function.

The GAA-API provides a mechanism to register a particular policy retrieval call-back function. Currently this is done using a configuration file.

The structure of the policy domains that contribute the policies is not specified explicitly in our framework. Only the hierarchical relationship (priority of the policy) among the domains is taken into consideration. Our current implementation supports two level policy specification: first, system-wide policies are retrieved and placed in the beginning of the list of policies. Then the local policies are retrieved and are added to the list. Thus, system-wide policies implicitly have higher priority than local policies.

The 26#26 function checks whether the requested right is authorized under the specified policy. This function takes the retrieved policy (an ordered list of EACLs), requested access right and contextual information as input. The contextual information is matched to the requirements, specified in the conditions of the relevant EACL entries (only the EACL entries where the the requested right appears are evaluated). For example, this information can be represented by a set of credentials, e.g., an X.509 identity certificate. The output lists all matching policy rights and associated conditions, with flags set to indicate whether each condition was evaluated and/or met. If the access is granted, the output includes the time period for which the result is valid.

27#27 performs policy enforcement during operation execution. This function checks whether the mid-conditions associated with the granted access right are met.

28#28 performs policy enforcement after the operation completes. This function enforces the post-conditions associated with the granted access.

A policy statement may specify several conditions of different types. For example: ``Tom can read file 5#5 only between 9am and 6pm''. This policy defines two pre-conditions: access identity and time. Both conditions are read conditions (there are two system variables to be read: user access identity and current time).

The GAA-API supports registering condition evaluation functions for different condition types.

The configuration file lists concrete functions that implement the conditions. The file is read at the GAA-API initialization time and the functions are registered with the specific conditions. In our policy example we define two functions: one to check the access identity and the other one to check the time. The read vs. write distinction shows up implicitly in the condition type. A condition evaluation function registered with a condition type knows whether the condition is read or write. It then parses the condition value and calls the concrete functions that implement the abstract 10#10 and 11#11 operations described in Section . The system variables manipulated by the 10#10 and 11#11 operations, as well as the operations themselves can be ether local or remote. However, our framework requires that the 10#10 and 11#11 operations must be implemented as atomic actions. The GAA-API is structured to support the addition of modules for evaluation of new conditions.

The 26#26, 27#27 and 28#28 functions return the evaluation status 29#29.

This status is obtained during the evaluation of conditions in the relevant EACL entries:
30#30 indicates that all conditions are met;
31#31 indicates that at least one of the conditions fails;
32#32 indicates that none of the conditions fails but there is at least one condition that is left unevaluated.

Uncertainty 32#32 is introduced into our framework by lack of adequate information to evaluate the condition. For example, a condition may depend on an event that has yet to happen. This means that the value of the system variable returned by the implementation of the abstract 12#12 operation is undefined. Another source of uncertainty is inability to find the corresponding condition evaluation function, for example if the function (12#12 or 14#14) is not implemented or not registered with the GAA-API. Sometimes, it is convenient to return some of the conditions unevaluated for further evaluation by the calling application.