Workflow

From UGP-Wiki

[edit] Workflow to add a user to both the user's local (Campus) Grid Portal and the Higher-Level Grid Portal

The workflow required to add a user to the Grid always begins at the Campus Grid Portal because it is on the Campus Grid level where the user has the strongest affiliation and is known. The workflowalways results in a user who has been added to both his/her Campus Grid Portal and to the UC Grid Portal.

In both figures, the part in the upper right, above the horizontal line represents what happens at the UC Grid Portal while the rest of the figure represents what happens at the Campus Grid Portal.

To login to a Grid Portal a user needs:

• A Grid certificate

• A GridSphere account on that Portal

Additionally:

• A Cluster User must be added to the gridmap file on the Grid Appliance connected to one of the clusters on which he/she has a login id as part of the creation process.

A Pool-Only user needs to be assigned a storage area on the Grid Portal’s Storage Server.

• A GridSphere account is required for each Grid Portal because UGP is built on top of the GridSphere Portal Framework and that framework requires the accounts. GridSphere is a portlet container that implements the JSR 168 standard. The use of GridSphere allowed UGP to be written in the form of portlets, the small, self-contained, pluggable user interface components that provide the functionality of the UGP.

The UC Register Service, shown in the figures at the UC level is required to make the single UC Grid CA and the single UC Grid username space work for the UC Grid and the Campus Grids.

The workflow starts when the user goes to the home page of his/her Campus Grid Portal and clicks the link that says “Apply for Grid Access”. This link will be absent from the UC Grid Portal. The first step will be for the user to authenticate. There are a number of ways that the user can do this:

• If the user is to be a Cluster User, ssh authentication can be used to prove that the user can login to a cluster. The cluster used for ssh authentication is automatically added to the user’s cluster access list.

• At UCLA, Shibboleth authentication is used for Pool-Only users. Shibboleth is the campus authentication method that knows about all UCLA-affiliated individuals: students, faculty, staff, etc.

At other campuses, whatever authentication method the campus is using can be used.

If, at some time in the future, a UC-Wide authentication method such as Shiboleth is initiated, it can be used.

After the user has authenticated and proved that he/she is eligible to join the Grid, the user will be presented with a form asking for his/her name, organization and other identifying information, as well as for a proposed Grid username and passphrase. This is the username and passphrase that the user will use to login to the Grid Portals.

A client to the UC Register Service will then contact that service to make sure that the proposed username is unique. If not, the user will be prompted for another selection until a unique username is found. The UC Register Service will then add that username and passphrase, along with the information about the user, in its database and mark it pending. ending records are purged from the database after a short period of time, less than 2 weeks, if they do not become permanent.

What happens next depends upon the user type. If the user is a Cluster User, a message is automatically sent to the cluster administrator of the cluster that the user used for ssh authentication, requesting that the cluster administrator add the user into the gridmap file on that cluster. The gridmap file is the link between the user’s Grid username and the user’s login id on that particular cluster. Included in the message is the Distinguished Name (DN) that will be in the certificate when it is created for that user. Every certificate has a Distinguished Name (DN), a string that includes the name of the issuing organization and unit, and the user’s common name (this is the user’s actual real full name). The cluster administrator must add the user’s DN and local login id as a record in the gridmap file for that cluster. Without this record, the Grid Portal cannot take any action on the user’s behalf on that cluster: listing files, submitting jobs, etc.

Once the cluster administrator has done this, he/she clicks on a link in the message he/she received. That takes him/her to the Campus Grid Portal where the cluster administrator must first authenticate and then click on a button indicating that he/she has approved the user and taken the requisite action. This causes a message to be sent to the Grid administrator for the campus.

Pool-Only Users cannot use a cluster in their own right. The step described above is skipped and a message is sent directly to the Grid administrator for the campus. The Grid administrator must take an additional step of creating a storage area for the Pool-Only User on the Storage Server associated with the Grid Portal.

If the Grid administrator for the campus approves the user, he/she clicks on a link in the message he/she has received and is taken to the Campus Grid Portal were the Grid administrator authenticates and then clicks on a button to indicate that he/she has approved the user. This automatically creates the GridSphere account on that portal and causes the UC Register Client to communicate with the UC Register Service on the UC Grid Portal that the user has been processed and approved.

The UC Register Service takes the following actions:

• Removes the pending mark from the user’s record in its database.
• Creates and signs the certificate for the user.
• Pushes the certificate to the UC MyProxy server.
• Pushes the certificate to the Campus MyProxy server.

The user can now login to both the Campus Grid Portal and the UC Grid Portal.