Local Resource Administration Service.

 

Local Resource Administration Service (LRAS) associates VO member with the local account and local resources based on the information provided by user in user proxy certificate. This service allows local resource provider (LRP) to manage fine grain access control to local resources.

 

The purpose of this document is to describe the way for Local Resource Providers (LRPs) to set up multiple resources and map them to a particular user, as well as to define the means to obtain this information.

 

The VOX project will provide Local Resource Administration Service package.

It is up to local administration to install/use it. The LRAS will have the means to periodically pull information from a particular VO about VO members and their groups' affiliation and store this information locally. The description of this mechanism is outside of the scope of this document.

 

Furthermore LRAS will include:

  1. LRAS Server: a server that authorizes/denies user's access to local cluster and provides mapping between user proxy information and abstract resource known to the server.
  2. LRAS DB: a database that contains the list of known VOs, list of groups within VO, available abstract resources, list of users', their access status, mapping to UNIX id and list of resources associated with each user.
  3. LRAS Client API:  API that allows client (e.g. gatekeeper, storage element) to connect with LRAS Server and fetch user's related information.
  4. LRAS Admin GUI: a graphical user interface that is used to facilitate LRPs to manage user access status, introduce new resources and map them to a particular user.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

LRAS current functionality

 

LRAS Database.

LRAS maintains the database that consists of information required to control grid user access to the local resources. This includes:

-         Contact information for multiple VOs

-         List of groups within VO

-         VO members’ Distinguished Name (DN) and name of Certificate Authority (CA) that issued it.

-         UNIX id associated with each (group, VO) tuple.

 

The database schema is shown below:

 

 

 

 

 

 

 

 

 

groups

The table stores information about all VOs that are approved by LRP, list of groups available within VO and their status in LRAS.

 

Field

Type

Is NULL

Default

Comments

vo

VARCHAR(250)

NOT NULL

 

VO contact string

gname

VARCHAR(250)

NOT NULL

 

Group name within VO

status

ENUM(“Y”,”N”)

NOT NULL

“N”

The indicator if members of the group are allowed in principal to access local resources

 

This table is initially populated by Update Daemon (see below); “status” can be changed by LRP via Admin GUI.

 

account

The table provides mapping between local UNIX id and a tuple (members’ VO, a particular group within VO). It also contains optional information about number of users that can be assigned to a particular UNIX id, as well as total number of users that are currently mapped to this id.

 

Field

Type

Is NULL

Default

Comments

vo

VARCHAR(250)

NOT NULL

 

VO contact string

gname

VARCHAR(250)

NOT NULL

 

Group name within VO

id

VARCHAR(10)

NULL

 

Unix id

maxUsers

TINYINT(3) UNSIGNED

NULL

NULL

Maximum number of users that can be assigned to this id

currUsers

TINYINT(3) UNSIGNED

NULL

NULL

Current number of users that are assigned to this id

 

This table is initially populated by Update Daemon (see below); “id” is set up by LRP via Admin GUI.

 

info

The table contains data related to grid users. It includes user’s DN and CA, as well as VO, group and role within VO and user’s access status in LRAS.

 

Field

Type

Is NULL

Default

Comments

dn

VARCHAR(250)

NOT NULL

 

User’s DN

ca

VARCHAR(250)

NOT NULL

 

User’s CA

vo

VARCHAR(250)

NOT NULL

 

VO contact string

gname

VARCHAR(250)

NOT NULL

 

Group name within VO

id

VARCHAR(10)

NOT NULL

 

Unix id

role

VARCHAR(250)

NOT NULL

 

Role name within group

allow

ENUM(“Y”,”N”)

NOT NULL

“Y”

The indicator if the grid user is allowed to access local resources

timeFrom

TIMESTAMP

NULL

 

Beginning of time slot when user is allowed/denied to execute his job

timeTo

TIMESTAMP

NULL

 

End of time slot when user is allowed/denied to execute his job

 

This table is initially populated by Update Daemon (see below), “allow”, “timeFrom”, “timeTo” can be set up by LRP via Admin GUI.

 

LRAS Database is in mysql.

LRAS Server.

 

LRAS Server is a daemon process that serves one or more grid clusters. It is running in passive mode waiting for clients’ requests. It is capable to handle multiple clients simultaneously. Upon receiving the certificate chain sent by the client it performs the following actions:

-         Authenticates client.

-         Verifies signature on certificate chain.

-         Checks the Certificate Revocation List (CRL) for validity of certificate.

-         Checks CA signing policy in order to verify that CA can issue this certificate.

-         Checks client authorization by queering LRAS database.

-         Determines clients UNIX id by queering LRAS database.

 

LRAS Server is implemented in Java.

 

 

LRAS Client API.

 

LRAS Client API (C library) can be used by LRAS client to communicate with LRAS Server by employing GSS/GSI mechanism. Currently it is capable of inquiring for UNIX id by supplying user certificate chain to the LRAS Server. The Client that wants to connect to LRAS Server and receive user mapping information should obtain user’s security context prior using LRAS Client API.

 

LRAS Client API allows performing the following actions:

·        Executes GSI handshake with LRAS Server.

·        Extracts the chain of certificates from user’s security context.

·        Transfers the chain to LRAS Server and receives back either user UNIX id or an error message.

 

At the present the only implemented client is a plugin that is called from the Gobus Gatekeeper during job submission.  The current implementation of Gatekeeper handles limited set of information: user permission to access the cluster (“Yes” or “No”) and a UNIX id under which Gatekeeper will submit user’s job.

 

 

 

 

 

 

 

 

 

 

 

 

 

 


LRAS Admin GUI.

LRAS Admin is a graphical user interface that allows LRP to administer LRAS. On startup LRP creates a configuration file that lists all VOs that ought to be contacted in order to get the list of VOs’ members. The polling interval for each VO is also defined in this configuration file. The LRAS Update Daemon (see below) periodically contacts all the VOs specified in configuration file, pulls relevant information and stores it in LRAS DB.

Using LRAS Admin, LRP should routinely perform the following tasks:

-         Define the status of a particular (VO, group) tuple 

-         Assign UNIX id to (VO,group) tuple

-         Manage user access to the grid clusters

 

LRAS Admin is implemented in Java. The examples of LRAS Admin screenshots are shown below:

 

LRAS Update Daemon.

 

LRAS Update Daemon is a process that fetches the groups and members information from the multiple VOs and populates LRAS database. Update Daemon collects members information only for (VO, group) tuples that are identified by LRP (status is set to “Y” in LRAS database) and have assigned UNIX id.  It also responsible for keeping LRAS DB in sync with information it obtains from VO.

 

LRAS Update Daemon is implemented in Java.

 

 

Grid Job Submission and LRAS.

 

The use case for grid job submission is described below:

 

1.      User obtains a proxy.

In order to submit job to the Grid, user has to obtain a valid proxy. This can be achieved by using either grid-proxy-init or voms-proxy-init. The proxy generated by voms-proxy-init contains information regarding user’s VO, his groups and role.

 

2.      User submits a job.

A user submits a job to a Gatekeeper that has callout plugins embedded in it. A gatekeeper passes user proxy to plugins.  LRAS Client plugin contacts LRAS Server and forwards user’s certificate chain to LRAS Server.

 

3.      LRAS Client passes the response form LRAS Server to gatekeeper.

4.      Gatekeeper either submits or rejects the user request for job submission based on this response (currently, user DN should be also in gridmapfile in order to successfully submit the job)

 

 


 proxy

 

job

 

 

 

 

 

 


Extended LRAS functionality.

 

The current implementation of LRAS supports mapping of user DN, CA, VO, Group and Role to UNIX id. In principle this information can be mapped to any abstract resources. An abstract resource is characterized by its name and value. For example user can be mapped to particular file system and access permissions, or to a batch queue with a particular name, etc. This information can be stored in the LRAS database in additional “resources” table (see below). “resource” table can be populated manually by LRP via LRAS Admin GUI .

 

 

Finally, “user to resource” mapping information can be obtained by using the LRA Client API (plugin). (In order to use this information during job submission via gatekeeper, either gatekeeper or Job Manager should be modified.)