Authorization Walk-through

Here we present two authorization scenarios.

First, let's consider a request from user Joe to run matlab on the host kot.isi.edu on Monday at 7:30 PM.

Assume that this host has the following ordered EACL stored in the Prospero Directory Service [4].

Figure 4 EACL for host kot.isi.edu

When a job manager contacts a system manager with the request for resources, the system manager calls ARDP, which handles authentication as explained in Figure 3 and Section 5.2.1. If Joe is authenticated successfully, then the verified identity credential is placed into the security context, specifying Joe as the Kerberos principal joe@ISI.EDU.

Then the system manager calls the gaa_get_object_policy_info function to obtain a handle to the EACL of kot.isi.edu. The upcall function for retrieving the policy for the specified object from the Prospero virtual file system is passed to the GAA API and is called by gaa_get_object_policy_info, which returns the EACL handle.

The system manager calls the gaa_check_authorization function asking if joe@ISI.EDU is authorized HOST:load matlab to kot.isi.edu.

In evaluating the EACL, the first entry applies. It grants the requested operation, however there are two restrictions that must be evaluated. The first restriction:

Token Type: time_window
Defining Authority: pacific_timezone
Value: 6AM-8PM

is generic and is evaluated directly by the GAA API. Since the request was issued on Monday at 7:30 PM this restriction is satisfied. The second restriction is PRM-specific:

Token Type: cpu_load
Defining Authority: local_manager
Value: 20%

If the security context passed by PRM defined a restriction evaluation function for upcall, then this function is invoked and if this restriction is met then the final answer is YES (authorized). During the execution of the task the node manager is monitoring if the task is abiding to the limits imposed on the local resources and authorization time. If the corresponding upcall function was not passed to the GAA API, the answer is MAYBE and the set of restrictions is returned. Restrictions are marked as ether evaluated or not evaluated. In our example the time_window restriction was evaluated and met; the cpu_load restriction was not evaluated and should be checked by PRM.

Next, we present an authorization scenario where additional credentials are needed. Let's consider a request from the same user Joe to shut down the node kot.isi.edu. The system manager calls gaa_check_authorization asking if joe@ISI.EDU is authorized to DEVICE:power_down host kot.isi.edu.

In the EACL evaluation, the first entry applies yet it does not grant the requested operation. The temporary answer is NO (not authorized). The second entry grants this permission, however the security context does not have group "operator" credentials. If the security context passed to the GAA API defines a credential retrieval function for upcall, then this function is invoked and if either a group membership credential for operation or delegated credential from user Tom for Joe is present, then the final answer is YES. If the credential retrieval upcall function was not passed to the GAA API, the answer is NO.