NVO SSO VMs

From MyWiki

We offer two routes to running an NVO Single Signon (SSO) system:

• From scratch on the Linux distribution of your choice, or
• From Virtual Machine (VM) images based on Fedora Core 5, in VMWare format, with all of the software pre-installed.

This page documents the second, simpler, option: installing NVO SSO from VM images.

Contents 1 Download VM Images 2 First Boot 3 Set passwords 4 Connect to the network 4.1 Private Development 4.2 External Visibility 4.3 Dealing with Firewalls 5 Regenerate CA (optional) 6 Update Certificates and Keys 6.1 Host Certificates 6.2 Pubcookie Symmetric Keys 7 Update Configuration Files 7.1 Application Server 7.2 Login Server 8 Reboot

Download VM Images

• login server (2.0 GB)
• application server (1.7 GB)

First Boot

1. Unpack the image and open it in any of the following:
   • VMWare Server, which is free, and good for lightweight server installations
   • VMWare Workstation, which has a free 30-day trial period and excellent checkpointing features
   • VMWare Player, also free, simpler than Server, but can only run one VM at a time
2. Start it up, behind NAT at first, which provides a firewall, until you change the default passwords

Set passwords

• The root password is the same as the image name (ssologin, ssoapp). Change it to something more secure.
• Set globus's password. The old one is cloWn3d.
• Login server only: Set the CA password; the old one is cloWn3d
  1. grid-change-pass-phrase -file /root/.globus/simpleCA/private/cakey.pem
  2. Update the following files, replacing the old password with the new one:
     • /usr/local/tomcat/webapps/purse/confirm.jsp
     • /usr/local/tomcat/webapps/purse/WEB-INF/purse.properties

Connect to the network

There are two options for network configuration, and which you choose depends on how you plan to use your VMs. By default, VMWare will set them up behind a NAT.

Private Development

If you are developing locally, and nobody else needs access to your VMs, you can set them up with what VMWare calls a "Host-only Network". They will each be assigned a private IP address that you can only reach from the computer on which VMWare is running. You can then assign them hostnames manually (in /etc/hosts, for example), or just use their IP addresses.

External Visibility

If, on the other hand, other people will need access to your VMs, VMWare can "bridge" your VMs' network connections so that they have their own addresses. To make your virtual machines externally visible on the network:

• Your network environment must allow multiple IP addresses on the same physical connection. Most routers will allow this.
• Set the virtual machine's ethernet connection to be "Bridged".
• VMWare will spoof a new MAC address; you may assign the virtual machine a DNS record.

Dealing with Firewalls

If you choose the second option above and make your VMs externally visible, your network's firewall, if there is one, may block some traffic. Here are the important ports (all TCP traffic):

• Application Server:
  1. 22 (ssh)
  2. 80 (apache http)
  3. 443 (apache https)
  4. 8080 (tomcat http)
• Login Server:
  1. 22 (ssh)
  2. 80 (apache http)
  3. 443 (apache https)
  4. 2222 (pubcookie keyserver — optional)
  5. 7512 (myproxy)
  6. 8080 (tomcat http)

Regenerate CA (optional)

If you plan to federate your login servers, you will probably want to create a fresh Simple CA instance, following the full installation instructions.

Update Certificates and Keys

Host Certificates

Your virtual machines will need new host certificates to go with their new hostnames. See the directions generating host certificates from the "From Scratch" instructions, or:

1. For an application server named <app-server>:
   • root@<login-server># grid-cert-request -host <app-server> -prefix <app-server> -cn <app-server>
   • root@<login-server># grid-ca-sign -in /etc/grid-security/<app-server>cert_request.pem -out /etc/grid-security/<app-server>cert.pem
   • root@<login-server># scp /etc/grid-security/<app-server>*.pem globus@<app-server>:~
   • root@<app-server>$ cp ~globus/<app-server>cert.pem /etc/grid-security/hostcert.pem
   • root@<app-server>$ cp ~globus/<app-server>key.pem /etc/grid-security/hostkey.pem
2. For your login server:
   • root@<login-server># rm /etc/grid-security/hostcert.pem /etc/grid-security/hostkey.pem /etc/grid-security/hostcert_request.pem
   • root@<login-server># grid-cert-request -host <login-server> -cn <login-server>
   • root@<login-server># grid-ca-sign -in /etc/grid-security/hostcert-request.pem -out /etc/grid-security/hostcert.pem
   • root@<login-server># cp /etc/grid-security/hostkey.pem /etc/grid-security/pubcookie_hostkey.pem
   • root@<login-server># chown apache.apache /etc/grid-security/pubcookie_hostkey.pem
3. Since the login server's host key is being used to sign Pubcookie keys, you'll need to copy its host certificate to the application server, replacing the old granting certificate:
   • root@<login-server># scp /etc/grid-security/hostcert.pem root@<app-server>:/usr/local/pubcookie/keys/pubcookie_granting.cert

Pubcookie Symmetric Keys

1. Pubcookie matches hostnames with symmetric key filenames. On your login server and all application servers, rename the keys in /usr/local/pubcookie/keys/ appropriately:
   • globus@<app-server>$ sudo mv /usr/local/pubcookie/keys/nvoapp1.ncsa.uiuc.edu /usr/local/pubcookie/<app-server>
   • root@<login-server># mv /usr/local/pubcookie/keys/sss.us-vo.org /usr/local/pubcookie/<login-server>
   • root@<login-server># mv /usr/local/pubcookie/keys/nvoapp1.ncsa.uiuc.edu /usr/local/pubcookie/<app-server>

Update Configuration Files

Application Server

1. /etc/httpd/conf/httpd.conf
   • In the LocationMatch directive, replace nvoapp1.ncsa.uiuc.edu with your application server's hostname.
2. /etc/httpd/conf.d/pubcookie.conf
   • Replace sso.us-vo.org with your login server's hostname.
3. /usr/local/pubcookie/config
   • Replace sso.us-vo.org with your login server's hostname.
4. /var/www/mod_myproxy/perl/Myproxy/Mod_Myproxy.pm
   • Replace sso.us-vo.org with your login server's hostname.
5. /usr/local/tomcat/webapps/ROOT/register.jsp
   • Replace sso.us-vo.org with your login server's hostname, in the action URL of the registration form.
   • Replace nvoapp1.ncsa.uiuc.edu with your application server's hostname, in the hidden returnURL input at the end of the form.
6. /var/www/mod_myproxy/perl/Nsa/Welcome_Constants.pm
   • Replace nvoapp1.ncsa.uiuc.edu with your application server's hostname, in the "create a new logon" link.

Login Server

1. /usr/local/pubcookie/config
   • Replace three instances of sso.us-vo.org with your login server's hostname.
   • Replace enterprise_domain .ncsa.uiuc.edu with your login server's domain.
2. /etc/myproxy-server.config
   • Replace nvoapp1.ncsa.uiuc.edu with one of your application server's hostnames.
3. /usr/local/tomcat/webapps/purse/WEB-INF/purse.conf
   • For values renewBaseUrl, myProxyHost, caBaseUrl, userBaseUrl, portalBaseUrl, and renewBaseUrl, replace sso.us-vo.org with your login server's hostname.
   • Do not update myProxyDN unless you have regenerated your CA, which is optional.
4. /usr/local/tomcat/webapps/purse/WEB-INF/purse.properties
   • For values portalBaseUrl, caBaseUrl, userBaseUrl, renewBaseUrl, and myProxyHost, replace sso.us-vo.org with your login server's hostname.
   • Do not update myProxyDN unless you have regenerated your CA, which is optional.
5. /usr/local/tomcat/webapps/purse/confirm.jsp
   • Replace two instances of nvoapp1.ncsa.uiuc.edu with your application server's hostname.
6. /usr/local/pubcookie/myproxy_fork.pl
   • Replace sso.us-vo.org with your login server's hostname.

Reboot

Or restart httpd, tomcat, and myproxy.

That should do it! If you would like help debugging, contact Bill Baker or Mike Freemon.