Using MyProxy For Session Passwords

National Center for Supercomputing Applications

University of Illinois at Urbana-Champaign

MyProxy > Docs > Developer's Guide > Creating And Authenticating Session Passwords With MyProxy

Session Passwords

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

Client A wants to authenticate a Username using a given Password. It sends U/P to the MyProxy Server.
MyProxy uses various mechanisms to see if U/P authenticates. For example, it can check any locally stored credentials for matching U/P, or it can authenticate to external sources via a Pluggable Authentication Module (PAM) or Simple Authentication and Security Layer (SASL).
If successfully authenticated, the MyProxy Server returns a new Credential.
Client A generates a new random (Session) Password (P') which will be used the next time a process wants to authenticate the Username. Note that while the client generates the password, the MyProxy server can enforce policies with respect to that password, e.g. minimum string length.
Client A stores the Credential on the MyProxy Server under U/P'. The client specifies the lifetime of this credential, which is then the lifetime of the Session Password. The MyProxy server may impose limits on this lifetime.

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

Client B has been given a short-lived Session Password P' and wants to authenticate a Username. It sends U/P' to the MyProxy Server.
MyProxy checks all local credentials stored under the Username for one with a matching Session Password P'.
Upon finding a matching stored credential, the MyProxy Server returns an "authentication okay" message and/or the credential to Client B.

Configuration of the MyProxy Server

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.

Install a MyProxy server. (Note that you should use version 3.7 or higher.)
Configure MyProxy to act as a Certificate Authority (CA).
Create a host certificate for your MyProxy server.
Configure external authentication with PAM (Pluggable Authentication Module) and/or SASL (Simple Authentication and Security Layer).
Modify your myproxy-server.config file for use with session passwords.

The last step of configuration for session passwords involves setting a few options in the myproxy-server.config file.

check_multiple_credentials "true" -
This is the configuration option which changes the behavior of the MyProxy server to work with session passwords. In a typical MyProxy server setup, you must specifiy the name of the credential you want to retrieve. If you provide no credential name, then you can only get the "unnamed" (default) credential for the username. When the check_multiple_credentials option is set to "true", a request for a credential without specifying a credential name initiates a search through all of the named (and unnamed) credentials stored on the server. If any of them match the request criteria, then that credential is returned. In this way, you can store multiple credentials for a given username using random (session) passwords and random credential names. When one of the session passwords is used to fetch a previously stored credential, all of the stored credentials are checked for a matching password. When one is found, the corresponding credential is returned, so we never need to worry about the credential name (other than storing the credential under a random, and hopefully unique, credential name).
certificate_mapfile "/full/path/to/mapfile" - OR -
certificate_mapapp "/full/path/to/mapapp" -
Since the MyProxy server is going to be generating credentials (by using the MyProxy Certificate Authority you configured earlier), you need to be able to map usernames to certificate subject distinguished names. If you have a static list of users for which you wish to generate session passwords, then you can use the mapfile. Otherwise, you will want to use the mapapp. Note that it is important that the certificate subject distinguished names you issue correspond to the server's CA distinguished name. If not, the MyProxy server may not allow you to put the issued credential back to the server.
accepted_credentials_mapfile "/full/path/to/mapfile" - OR -
accepted_credentials_mapapp "/full/path/to/mapapp" -
This option prevents a user from storing his credential under a username other than his own. As before, if you have a static list of usernames, then use the mapfile. Otherwise use the mapapp.

Testing the Myproxy Server Setup

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.

Install the Root Certificate

When you configured MyProxy to use SimpleCA, you created a root certificate for your server. This root certificate consists of two files.

  /etc/grid-security/certificates/84c59fba.0
  /etc/grid-security/certificates/84c59fba.signing_policy

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/

Test Using MyProxy Command Line Programs

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.

Test Using the Java Client API

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.