 |
The following steps describe the normal usage of the GridShib-CA by a user.
User visits index.html with browser. Is directed to logon by clicking on form submit button.
By clicking on logon button, use is sent to login.cgi. This will cause Shibboleth authentication. The main job of login.cgi is to ensure that the user's shibboleth identity is accessible and valid. User is directed to click a submit button to retrieve their credentials, which invokes the create-jnlp CGI script. Additionally, login.cgi sets a cookie and a form element to provide for CSRF protection as described in Cross-Site Request Forgeries: Exploitation and Prevention.
The create-jnlp script checks the CSRF element and cookie that should have been set by login.cgi and make sure they match. It then creates the JNLP file to launch the Java Web Start application. The JNLP file contains the following arguments for the CredentialRetrieve Java app:
3.a. the URL for the generateCred.pl script (step 6)
3.b. The user's Shibboleth Session cookie
3.c. An encrypted token so that CredentialRetriever can assert that it was legitimately invoked.
3.d. Whether or not the client should run in debug mode.
3.e. The lifetime requested by the user for the credential.
3.f. The URL from which the client can receive trusted CAs (step 10)
3.g. Optionally a parameter telling the client not to use its bundled CAs to validate its https connections (steps 2,3,6 and 10)
The web browser saves the jnlp file to disk and launches Java Web Start, passing it the jnlp file.
Java Web Start downloads the GridShib jar file as directed by the JNLP file, and launches the CredentialRetriever class from the jar, passing it the Shibboleth Session, Token and URL from the JNLP file as arguments.
CredentialRetriever runs, creates a key pair and certificate request. CredentialRetriever uses the Shibboleth Session received via the JNLP file to authenticate to generateCred.pl as if it were the user's web browser. It passes the following to generateCred.pl:
6.a. certificateRequest: The certificate request as PEM encoded PKCS10.
6.b. token: The encrypted Token generated by login.cgi
generateCred.pl validates the Token received and then hands off the certificate request a CA (either a local OpenSSL-based CA or a MyProxy-based CA) for signing, receiving the signed certificate in return.
generateCred.pl returns the certificate to Credential Retriever.
CredentialRetriever writes the certificate and private key to local disk in the location expected by Globus Toolkit and compatible software.
Assuming the server is configured to provide trusted CA certificates to the client, the client connects to the getTrustedCAs.cgi script, doing a GET (providing no parameters). The script in returns a list of files (CA certificates and signing policies) for the client to install, using the following format, where each file is separated with a line containing the filename and a fixed prefix:
-----File: aa99c057.0 ...certificate data... -----File: aa99c057.signing_policy ...signing policy data... ...and so forth...
The client writes the returned CA files and policies to the clients trusted certificates directory (normally ~/.globus/certificates).