Single Sign-on (SSO) with Non-Default Certificates

Home > User Info > Access > SSO sith non-default certificates

If you will be computing or transferring data across multiple TeraGrid resources, and you need to use a certificate from a different CA (not the default certificate issued for the TeraGrid by theNCSA CA), then you will need to manually enable Single Sign-on. This requires performing a set-up procedure at all the sites where you will be computing so that your user certificate will be recognized by each TeraGrid resource. Once you have successfully completed the steps below, you will have single sign-on capabilities across the TeraGrid resources. That is, you can make any TeraGrid resource site the starting point for all your grid computing.

Procedure

1. Install an X.509 certificate  (Do this once only)
2. Create a Distinguished Name (DN) entry in each site's grid-mapfile (Do once)
3. Verify success at each site (Do once)
4. Set up a proxy certificate  (Repeat for each computing or data storage session)

Using the default TeraGrid certificate? Return to the Access Overview page. Set-up is automated. Do not continue with the steps on this page.

Researchers who need to use a certificate other than the one issued for the TeraGrid by the NCSA CA will need to use or obtain one from the list below and proceed with the steps on this page.

1. Create an X.509 Certificate

After you have received your account information packet in the mail, obtain ONE certificate from an accepted Certificate Authority (CA) below. One certificate can be used for all sites. If you already have a valid certificate from the following list, you do not need a new one. Follow the directions provided from the site that you select below.

Files Created by CAs

Certificate authorities typically create at least two files, stored in a .globus directory:

• usercert.pem - Your digital certificate, signed by the CA daemon
• userkey.pem - Your private key matching the public key contained in your usercert.pem

In some cases (such as when the "cacl" command is used), a file called usercert.p12 is created. This is a private key and, although it is encrypted, should not be copied or sent to other parties. This file is used by web browsers.

2. Set up a DN entry in each site's grid-mapfile

Once you have a certificate, you need to create a DN entry in the grid-mapfile at each of the sites where you will be grid computing. A DN is a globally unique identifier that represents you as an individual. gx-request is the command used to accomplish this. After the grid-mapfile at each site has been updated with your DN entry, you will be able to use single-sign on to work on all resources where you have an allocation. That is, you will login only once each session by initiating a certificate proxy session. You will use the passphrase that you used to install your certficate.

Example of a TeraGrid certificate DN:

NCSA DN
/C=US/O=National Center for Supercomputing Applications/CN=Jane Doe

Please note that the gx-request command replaces gx-map, although you may still see references to gx-map in documents and in the INCA monitoring systm, since gx-map is still the name of the application.

gx-request can be run with a number of parameters:

• -quick-add and -quick-remove: these options added in 2007 are quicker and easier than -interactive. They automatically extract the DN for you from your current proxy or from your user certificate in your .globus file if you created that in the previous step. If you have neither, it fails with an error message, and you can try again with -interactive to specify the DN manually. gx-request -quick-add shows the extracted DN and asks for verification before submitting the request.
• -interactive: takes you step by step through the process. If you use this method, you may have to supply the DN manually. Instructions for finding your DN are below. See a sample session for gx-request -interactive.
• -help: a brief usage message
• -long-help: a list of all the options
• man gx-request: full details

If you can't use gx-request -quick-add, and you use gx-request -interactive, the process will interactively prompt for the information it needs. (see sample gx-request -interactive session) One of the steps asks for the DN entry. You will need to find your DN. See Identify your DN below. Once the request is submitted, the update should occur within a few minutes.

Identify Your DN at IU, NCSA, ORNL, SDSC, UC/ANL

Log in to the machine where your certificate resides (usually in a .globus directory under your home directory), and issue the following command to see your DN:

grid-cert-info -subject

The following is an example response for an NPACI user:

/C=US/O=NPACI/OU=SDSC/CN=FullName/ \
0.9.000.000300.100.1.1=username

3. Verifying Your Certificate & DN

To see if your DN has been added to a site's grid-mapfile, log into a TeraGrid platform at that site and issue the following command (replace "your_username" with the appropriate username for your account):

% grep your_username /etc/grid-security/grid-mapfile

4. Create a Certificate Proxy

Once your DN is located in the grid-mapfiles of all the resources where you plan to compute, you are ready to start using Single Sign-on. To initiate each session, you will need to create a certificate proxy. This short-term credential will allow you to connect to multiple resources without logging in separately to each one. Creating a proxy must be done each time you wish to initiate a work session on the TeraGrid. Creating a proxy the first time is another way to test that our certificate and DN have been properly propagated.

See the "Certificate Proxy" page, for instructions on the final step required to enable Single Sign-on (authentication by certificate) across TeraGrid sites.

Exceptions for PSC and SDSC