Fine-grained authorization for job and resource management usingakenti and the globus toolkit(R) Page: 2 of 7
This article is part of the collection entitled: Office of Scientific & Technical Information Technical Reports and was provided to Digital Library by the UNT Libraries Government Documents Department.
The following text was automatically extracted from the image on this page using optical character recognition software:
CHEP 03, La Jolla, Mar 24-28, 2003
for stakeholders to understand and must be extensible to
allow for many types of resources and conditions.
In summary, the challenging access control
requirements that we address are as follows:
" Providing flexible policy-driven access control
" Federating policy from several independent sources
" Allowing long-running jobs to be treated as objects
whose management is subject to access control
" Integrating with the current GT2 job submission
mechanism with a minimum disturbance for the
client or the service provider
3. AUTHORIZATION IN THE GLOBUS
We assume the following model for job submission and
control. An interaction is initiated by a user submitting a
request to start a job, including the job description,
accompanied by the user's Grid credentials, in the form of
an X.509 certificate . In the current case this is just an
identity certificate and asserts no other attributes about the
user. This request is then evaluated by an access control
decision function (ADF) which may be called from
several different access control enforcement functions
(AEFs) located in the resource management modules. If
the request is authorized, it is started under a local
credential (i.e., userid).
During the job execution, a VO user may submit
management requests composed of a management action
(e.g., request information, suspend or resume a job, cancel
a job). The resource manager may decide to perform the
action or to pass it on to the locally executing job.
In order to perform these transactions, the Globus
Resource Acquisition and Management (GRAM) 
system is used. GRAM has two major software
components: the gatekeeper and the job manager. The
gatekeeper is responsible for translating Grid credentials
to local credentials (e.g. mapping the user to a local
account based on their Grid credentials) and creating a job
manager instance to handle the specific job invocation
request. The job manager is a Grid service which
instantiates and then provides for the ability to manage a
job. Figure 1 shows the interaction of these elements; in
this section we explain their roles and limitations.
The GRAM gatekeeper is responsible for authenticating
the requesting Grid user, authorizing a job invocation
request, and determining the account in which the job
should be run. Authentication, done using the Globus
Toolkit's Grid Security Infrastructure (GSI) , verifies
the validity of the presented Grid credentials, the user's
possession of those credentials, and the user's Grid
identity as indicated by those credentials. Authorization is
based on the user's Grid identity, the site's trust policy,
and the site grid-mapfile, which maps each allowed Grid
identity to a local userid.
The gatekeeper then starts a job manager instance,
executing with the user's local credential. This mode of
operation requires the user to have an account on the
resource and implements fine-grained access enforcement
by privileges of the account.
. authenticate user
* authorize user against
" map grid credential to
Create a grid
Start an application
. no authorization on job
Client Job control . limited authorization on
User Cred Hjob control
Figure 1 Interaction of the main components of GRAM
3.2. Job Manager
The GRAM job manager parses the user's request,
including the job description, and calls the resource's job
control system (e.g., exec, LSF, PBS) to initiate the user's
job. During the job execution the job manager monitors its
progress and handles job control requests (e.g., suspend,
stop, query) from the user. Since the job manager instance
is run under the user's local credential, as defined by the
user's account, the operating system, and local job control
system are able to enforce local policy on the job manager
and user job by the policy tied to that account.
The job manager does no authorization on job startup
because the gatekeeper has already done so. Once the job
has been started, however, the job manager accepts,
authenticates, and authorizes management requests on the
In GT2, the authorization policy on these management
requests is static and simple: the Grid identity of the user
making the request must match the Grid identity of the
user who initiated the job.
4. AKENTI AUTHORIZATION SERVICE
As noted in Section 1, the authorization provided by
GT2 is coarse grained. Because of the large user
community, the NFC needed to add fine-grained
authorization for job execution and management. Rather
than writing an authorization function from scratch, the
Here’s what’s next.
This article can be searched. Note: Results may vary based on the legibility of text within the document.
Tools / Downloads
Get a copy of this page or view the extracted text.
Citing and Sharing
Basic information for referencing this web page. We also provide extended guidance on usage rights, references, copying or embedding.
Reference the current page of this Article.
Thompson, Mary R.; Essiari, Abdelilah; Keahey, Kate; Welch, Von; Lang, S. & Liu, Bo. Fine-grained authorization for job and resource management usingakenti and the globus toolkit(R), article, July 1, 2003; Berkeley, California. (digital.library.unt.edu/ark:/67531/metadc873930/m1/2/: accessed February 16, 2019), University of North Texas Libraries, Digital Library, digital.library.unt.edu; crediting UNT Libraries Government Documents Department.