Shibboleth Software dependencies

External dependencies

Services which need to be in place for the Shibboleth Identity Provider to operate.

• Local infrastructure to provide authentication and attributes (should be in place from test installation)
• NTP server to ensure accuracy of server clock. This should be kept to within about a minute of the correct time. To do so, NTP updates are probably not required more frequently than about once a week, but if problems are detected, more frequent updates might be required (see ShibDiagnostics).
• Firewall requirements: the Identity Provider server should be able to accept incoming secure HTTP connections on ports 443 and 8443, and to make outgoing http requests (for metadata refreshing). This needs to be configured both on the local machine and in any network firewall.

Local dependencies

• Apache 2 with ssl/mod_ssl (and with installed server certificates - which need to be ones acceptable in the federations the institution wishes to join). This software will generally be part of the distribution, if a Linux or other Unix system is to be used for the installation. Note that the official installation guide describes the use of certificates which are suitable for a test installation but lack the assurance necessary for a production system.
• Java 1.5 (5.0) JDK - the Shibboleth web site documentation says that 1.4.2 is also possible, but that has bugs which prevent the issuing of persistent IDs to users, which is a requirement for Athens gateway use
• Tomcat 5.5 (choose the current stable release)
• mod_jk - mod_jk2 will also work but is deprecated (as development work on mod_jk2 has apparently stopped)

Instructions on how the components should be configured to work together are given in the http://shibboleth.internet2.edu/guides/idp/installinfo.html#step1 . First, you need to configure mod_jk to re-direct Shibboleth queries to Tomcat (Section C), then add the authentication configuration to Apache (Section E) - though following the test installation for details of Apache authentication rather than the instructions here. In both cases, it should be possible to copy existing configuration information from the test installation and reuse it with minimal modification. Note that in Section C of the installation guide, there are two errors:

1. There is no "<Ajp13Connector> configuration element" in the server.xml file. Instead, the mod_jk configuration section in the file to be altered follows the comment <!-- Define AJP 1.3 connector -->.
2. Ignore sub-sections 6-8; these deal with the mod_jk2 connector only (this was found to be unclear by testers)

Startup Scripts

It is important to start up the server components (Apache and Tomcat) when the installation machine is rebooted. It will generally be the case that startup scripts for Apache will be included in the software installed on the machine already, but this will probably not be true for tomcat. Attached here is a file which can be used as a Tomcat startup script. In order to use it, it needs to be installed on the machine:

1. Save the file as tomcat in /etc/rc.d/init.d.
2. It may be necessary to edit the configuration at the top of the script; CATALINA_HOME needs to be the directory in which tomcat is installed; JAVA_HOME needs to be the directory in which Java is installed; and TOMCAT_OWNER needs to be the user which owns the directory in which tomcat is installed.
3. In each of the directories /etc/rc.d/rc1.d, /etc/rc.d/rc2.d, /etc/rc.d/rc4.d, /etc/rc.d/rc5.d, /etc/rc.d/rc6.d, create a symbolic link to this file named K13tomcat: % ln -s ../init.d/tomcat K13tomcat .
4. In the directory /etc/rc.d/rc3.d, create a symbolic link to the file named S87tomcat: % ln -s ../init.d/tomcat S87tomcat .

Simon McLeish - 29 Sep 2005