Much of the information here is taken from the paper Single Sign-On for Java Web Start Applications Using MyProxy presented at the 2006 ACM Workshop on Secure Web Services, a workshop of the 13th ACM Conference on Computer And Communications Security. Also available are PowerPoint Slides presented at the workshop.
A MyProxy server can be configured to assist in the creation and utilization of "session passwords". A session password, a term borrowed from session keys in cryptographic protocols, is a short-lived password which can be used in place of a user's long-lived password. The basic idea is as follows. The MyProxy server issues a credential for a username. The client generates a random password and stores the credential back to the MyProxy server under the username using this random password and a random credential name. The client then passses this random password to another process needing to authenticate the username. The generation of a session password is illustrated below.
Figure 1 - Creating a short-lived "session password" with MyProxy
At the end of this process, Client A has a session password P' which can be sent along with the Username to another machine/process. That machine/process would authenticate the Username using P' as the Password. This is illustrated below.
Figure 2 - Using a short-lived "session password" with MyProxy
In order to be used for session passwords, the MyProxy server must be configured with specific options. Once a MyProxy server is configured in this manner, it should be used exclusively for session passwords. This page will not go into the details of installing a MyProxy server. Rather, links to the appropriate pages are provided, and just the specific options for session passwords are discussed in detail.
The last step of configuration for session passwords involves setting a few options in the myproxy-server.config file.
You can test your configuration by running a client on the same machine as the MyProxy server, but to make sure everything is working remotely, you should test from a separate client machine. There are two ways to do this: (a) using MyProxy command line tools and (b) using a Java test application. Both methods require that the client is configured with the server's root certifcate.
When you configured MyProxy to use SimpleCA, you created a root certificate for your server. This root certificate consists of two files.
Note that the 84c59fba is an 8 character hex string and will be different for your server. Copy these two files to every client machine that will be contacting the MyProxy server for user authentication. Copy them to your home directory in the "~/.globus/certificates/" directory (or "%HOMEPATH%\.globus\certificates\" in MS-Windows). Commands for *nix would look like this.
mkdir -p ~/.globus/certificates cp 84c59fba.* ~/.globus/certificates/
In MS-Windows, you will need to start a "command prompt" window (e.g. Start->Run..., type cmd, and then <Enter>) and then type the following commands.
mkdir %HOMEPATH%\.globus\certificates copy 84c59fba.* %HOMEPATH%\.globus\certificates\
If you are going to use the Java application on *nix to test your setup, you will also need to copy these root certificate files to your "/etc/grid-security/certificates/" directory as root. This can be done as follows.
mkdir -p /etc/grid-security/certificates cp 84c59fba.* /etc/grid-security/certificates/
In order to test your setup using MyProxy command line tools, you will need to install the MyProxy-specific version of the Globus Toolkit v4.0.3. You can do this as you did before with the server. Once you have MyProxy installed on the client machine, execute the following commands. (Entries marked in red italic must be changed to suit your particular setup.)
myproxy-logon -s myproxy.server.host.com -l username -o cred1 Enter MyProxy pass phrase: (enter password, not echoed) A credential has been received for user username in cred1. myproxy-init -s myproxy.server.host.com -l username -C cred1 -y cred1 -c 0 -a -k cred1 Your identity: /C=US/O=myproxyserver/OU=Company/CN=username Creating proxy ......................................................... Done Proxy Verify OK Your proxy is valid until: Sat Sep 30 01:54:23 2006 Enter MyProxy pass phrase:(enter (NEW)SessionPassword, not echoed) Verifying - Enter MyProxy pass phrase:(re-enter SessionPassword, not echoed) A proxy valid for 11 hours (0.5 days) for user username now exists on myproxy.server.host.com. myproxy-logon -s myproxy.server.host.com -l username -o cred2 Enter MyProxy pass phrase: (enter SessionPassword, not echoed) A credential has been received for user username in cred2.
So what is going on here? The first myproxy-logon command contacts the MyProxy server with the username and saves a new credential for that user in the file "cred1". You can view the contents of this credential with the following openssl command.
openssl x509 -noout -text -in cred1
This new "cred1" was created by the MyProxy server using its SimpleCA functionality. MyProxy contacted an external user database using PAM or SASL, got successful authentication, and then returned a new credential on-the-fly.
The next myproxy-init command puts this cred1 credential BACK to the MyProxy server under the same username but with a NEW "session password" that you made up. You also had to specify a credential name ("cred1" in this case using the "-k" option, but it could be anything). We won't care about the credential name in the future because MyProxy has been configured to check all stored credentials for a matching password.
Finally, the last myproxy-logon command uses the NEW "session password" that you just created to fetch another credential and store it in the file "cred2". You will notice that this new credential is different from the first credential. In fact, the new credential is a proxy credential based on the first credential. You could then put this second credential back to the MyProxy server under a different credential name using another "session password". Future authentication attempts with either password would return a new credential.
An alternative way of checking your MyProxy server setup is by using a Java client program. For this, you will need to install Sun's Java (version 1.4.2 or higher) as well as a few JARs. So download the following files.
Untar the two tarballs to any directory you want. You will be using several JAR libraries in your CLASSPATH so you only need read access. Let's assume you untarred them to the /tmp directory. The full commands would look something like this.
cd /tmp wget http://security.ncsa.uiuc.edu/research/wssec/gsihttps/SSOUtils.java wget http://www-unix.globus.org/ftppub/gt4/4.0/4.0.3/ws-core/bin/ws-core-4.0.3-bin.tar.gz wget http://apache.oregonstate.edu/jakarta/commons/lang/binaries/commons-lang-2.1.tar.gz tar xvzf ws-core-4.0.3-bin.tar.gz tar xvzf commons-lang-2.1.tar.gz mkdir -p edu/uiuc/ncsa/myproxy mv SSOUtils.java edu/uiuc/ncsa/myproxy/ export CLASSPATH=.:\ /tmp/ws-core-4.0.3/lib/cog-jglobus.jar:\ /tmp/ws-core-4.0.3/lib/log4j-1.2.8.jar:\ /tmp/ws-core-4.0.3/lib/cryptix32.jar:\ /tmp/ws-core-4.0.3/lib/cryptix-asn1.jar:\ /tmp/ws-core-4.0.3/lib/puretls.jar:\ /tmp/ws-core-4.0.3/lib/jce-jdk13-125.jar:\ /tmp/commons-lang-2.1/commons-lang-2.1.jar javac edu/uiuc/ncsa/myproxy/SSOUtils.java
After all that, you should have a newly compiled class file in "/tmp/edu/uiuc/ncsa/myproxy/SSOUtils.class". You can now run the test application as follows. (As before, entries marked in red italic must be changed to suit your particular setup.)
java edu.uiuc.ncsa.myproxy.SSOUtils username password myproxy.server.host.com
You should see plenty of "Succeeded!" messages if everything is configured correctly. The Java code is doing basically the same thing as the MyProxy command line tool commands shown before.
The SSOUtils.java file also contains several utility methods that you can use in your own Java code. Look at the comments in the file for more information. Basically you should use "createSessionPassword" to take in a username/password and return a NEW "session password", and "authenticateUser" to take in a username/password and return an "authentication OK" value. Note that both methods can take either the user's original password or a newly created "session password". Once a session password has been created, it will remain valid until it expires (default value is 4 hours). So you can create multiple session passwords for any given username.