Page History

...

We use the native Red Hat RPMs (5.0), part of the standard NIST install.

Database initialization

Start up the daemon, and secure the installation:

...

Respond to the prompts to set the root password, remove anonymous users, disallow remote root logins, and remove the test database.

We use a master/slave configurationreplication, where all queries go against one MySQL master server (e.g. idp-cams-1), while the other server (e.g. idp-cams-2) operates in slave mode, i.e. with updates to the master replicated to the slave. Set up the master server first, before setting up replication.

To set up the Cams database, restore from the most recent good backup on to the master (if setting up both the master and slave servers, do this on both servers, i.e. before configuring them as master and slave).

# mysql -u root -p < /path/to/most-recent-backup.sql

If initializing a new database for some reason, process the database schema file, a copy of which can be found in /mit/touchstone/config/idp2-cams/cams/camsdb.sql.

Grant tables

The grant tables The grant tables will likely need to adjusted for when moving an existing database to a new server host, e.g. if the master or slave host names are changing.

If initializing a new database for some reason, process the database schema file, a copy of which can be found in /mit/touchstone/config/idp2-cams/cams/camsdb.sql.

Install Shibboleth IdP

...

The CAMS application will use the camsusr account to access the CAMS database; the Shibboleth IdP resolver will use the shibresolver account; the database backup cron job uses the backup account; the cams-ldap daemon uses the camsldap account. Create the following accounts as needed (replace <password> with the password for that account):

# mysql
mysql> GRANT ALL ON cams.* TO 'camsusr'@'localhost' IDENTIFIED BY '<password>';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT ALL ON cams.* TO 'camsusr'@'idp-cams-1.mit.edu' IDENTIFIED BY '<password>';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT ALL ON cams.* TO 'camsusr'@'idp-cams-2.mit.edu' IDENTIFIED BY '<password>';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT SELECT ON cams.* TO 'shibresolver'@'localhost' IDENTIFIED BY '<password>';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT SELECT ON cams.* TO 'shibresolver'@'idp-cams-1.mit.edu' IDENTIFIED BY '<password>';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT SELECT ON cams.* TO 'shibresolver'@'idp-cams-2.mit.edu' IDENTIFIED BY '<password>';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT SELECT, LOCK TABLES, FILE, RELOAD ON *.* TO 'backup'@'localhost' IDENTIFIED BY '<password>';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT SELECT ON cams.ExternalUser TO 'camsldap'@'localhost' IDENTIFIED BY '<password>';
Query OK, 0 rows affected (0.00 sec)

mysql> quit

h4. Install Shibboleth IdP
* Run the idp application installer from our customized binary distribution, available in /mit/touchstone/builds/NIST/idp2-cams/cams-shibboleth-identityprovider-2.x.y-bin.tgz, and the install script contained therein.  For example

...

:

1. cd /tmp
2. rm -rf

...

1. shibboleth-identityprovider-2.*

...

2. tar

...

1. xzf

...

1. /path/to/cams-shibboleth-identityprovider-2.1.5-bin.tgz

...

2. cd

...

1. shibboleth-identityprovider-2.1.5

...

2. ./install.sh

...

1. 
   There

...

1. should

...

1. be

...

1. no

...

1. need

...

1. to

...

1. override

...

1. the

...

1. default

...

1. responses

...

1. to

...

1. the

...

1. installer's

...

1. questions.

...

1. No Format

...

1. By default (because of one of our customizations to the stock Internet2 distribution) this will install

...

1. under {{/usr/local/shibboleth-idp/}}. The installer will not overwrite the configuration files of an existing installation. For a new installation, the installer will generate a keystore, and prompt for its password; currently we do not use this keystore, so the password does not matter. This distribution contains the standard shibboleth-identityprovider binary distribution, from the Internet2 zip file (http://shibboleth.internet2.edu/downloads/shibboleth/idp/latest/

...

1. ), plus the following customizations:

...

1. ** camslogin This provides the custom login pages for CAMS users. It is available as a tarball (/mit/touchstone/builds/NIST/idp2-cams/camslogin.tgz) which is unpacked into the top-level directory of the binary distribution.

...

1. ** CamsLoginModule (cams-jaas-loginmodule-x.y.jar)

...

1. This is the JAAS login module for CAMS. It is available as a .jar file in /mit/touchstone/builds/NIST/cams-jaas-loginmodule-x.y.jar, where x.y is the version number (currently 1.0). It must be copied into the lib subdirectory of the binary distribution.

...

1. ** camsutil-1.0.jar

...

1. This is a helper package used by the login module to validate the username/password. It is available in /mit/touchstone/builds/NIST/camsutil-1.0.jar. It must be copied into the lib subdirectory of the binary distribution along with the login module jar file.

...

1. * The installer will create and populate /usr/local/shibboleth-idp; the web application (war) file will be in /usr/local/shibboleth-idp/war/idp.war, but the current version of the idp.war will be available in the locker (/mit/touchstone/builds/NIST/idp2-mit/idp.war).

...

1. * The idp application, running under Tomcat, needs full access to the install directory, so make sure it is owned by the tomcat user, e.g.:

...

...

1. chown

...

1. -R

...

1. tomcat:tomcat

...

1. /usr/local/shibboleth-idp

   No Format

...

1. To ensure that we run the current version of the web application, download the latest idp.war file from the touchstone locker (/mit/touchstone/builds/NIST/idp2-mit/idp.war) and copy it into /usr/local/tomcat/webapps/:

...

1. cp

...

1. /path/to/idp.war

...

1. /usr/local/tomcat/webapps/

...

2. chown

...

1. tomcat:tomcat

...

1. /usr/local/tomcat/webapps/idp.war

   No Format

...

1. * Copy the idp's endorsed jar files to tomcat's endorsed dir:

...

...

1. mkdir

...

1. -p

...

1. /usr/local/tomcat/endorsed

...

2. cp

...

1. -p

...

1. /usr/local/shibboleth-idp/lib/endorsed/*.jar

...

1. /usr/local/tomcat/endorsed/

...

2. chown

...

1. -R

...

1. tomcat:tomcat

...

1. /usr/local/tomcat/endorsed

   No Format

...

1. * Copy in the idp config files for the server, to the conf subdirectory; these include:

...

1. ** attribute-filter.xml

...

1. ** attribute-resolver.xml

...

1. ** handler.xml

...

1. ** internal.xml

...

1. ** logging.xml

...

1. ** login.config

...

1. ** relying-party.xml

...

1. ** service.xml

...

1. ** tc-config.xml (for terracotta clustering)

...

Terracotta

1. h4. Terracotta (See https://spaces.internet2.edu/display/SHIB2/IdPCluster

...

1. )

...

1. The terracotta software is used to cluster the IdP nodes. Each node must run the terracotta server, as well as the instrumented client (tomcat, in our case). The terracotta server operates in either the active or passive role; only one server should be in the "active/coordinator" state at a time.

...

1. Download the terracotta tarball; our current version is in the touchstone locker, in /mit/touchstone/downloads/terracotta-x.y.z.tar.gz. Extract it under /usr/local, create a logs directory for it, make it owned by the tomcat user, and symlink /usr/local/terracotta to it. For example (replace 3.1.1 with the appropriate terracotta version number):

...

...

1. cd

...

1. /usr/local

...

2. tar

...

1. xzf

...

1. /path/to/terracotta-3.1.1.tar.gz

...

2. mkdir

...

1. -p

...

1. terracotta-3.1.1/logs

...

2. chown

...

1. -R

...

1. tomcat:tomcat

...

1. terracotta-3.1.1

...

2. rm

...

1. -f

...

1. terracotta

...

2. ln

...

1. -s

...

1. terracotta-3.1.1

...

1. terracotta

   No Format

...

1. The IdP requires the installation of a couple of Terracotta Integration Modules, and the generation of a boot jar file for Tomcat, which is specific to the Java version:

...

...

1. setenv

...

1. TC_HOME

...

1. /usr/local/terracotta-3.1.1

...

2. setenv

...

1. TC_INSTALL_DIR

...

1. $TC_HOME

...

2. setenv

...

1. JAVA_HOME

...

1. /usr/java/default

...

2. $TC_HOME/bin/tim-get.sh

...

1. install

...

1. tim-vector

...

1. 2.5.1

...

1. org.terracotta.modules

...

2. $TC_HOME/bin/tim-get.sh

...

1. install

...

1. tim-tomcat-6.0

...

1. 2.0.1

...

2. $TC_HOME/bin/make-boot-jar.sh

...

1. -f

...

1. /usr/local/shibboleth-idp/conf/tc-config.xml

   No Format

...

1. *Be sure to regenerate this jar after installing a new JDK.

...

1. * Install the init script from /mit/touchstone/maint/shibboleth-idp/terracotta/terracotta.init in /etc/init.d, and make sure it is configured to start at boot time. Note that terracotta must be started before tomcat.

...

1. cp

...

1. /path/to/terracotta.init

...

1. /etc/init.d/terracotta

...

2. chmod

...

1. 755

...

1. /etc/init.d/terracotta

...

2. chkconfig

...

1. --add

...

1. terracotta

   No Format

...

1. To avoid performance impact during business hours, we disable automatic garbage collection of terracotta objects. Instead, we run a nightly cron job to do the garbage collection manually. Since this should only be done on the active/coordinator node, the script, run-dgc-if-active.sh, checks the server mode, then runs the garbage collector if and only if the server is the active node. Both the script and cron file can be obtained in /mit/touchstone/maint/shibboleth-idp/terracotta/; install as follows:

...

...

1. cp

...

1. /path/to/run-dgc-if-active.sh

...

1. /usr/local/shibboleth-idp/bin/

...

2. cp

...

1. /path/to/run-dgc.cron

...

1. /etc/cron.d/run-dgc

...

1. No Format

   h4. Shibboleth SP The CAMS application needs to authenticate against our IdPs, and so requires the Shibboleth service provider (SP) software to run, as well as the IdP software. h5. Installation We use the stock RHEL 5 64-bit RPMs, available from the [Internet2 downloads site|http://download.opensuse.org/repositories/security://shibboleth/RHEL_5/x86_64/]; the current RPMs are available in the touchstone locker downloads directory. Install the following RPMs: * log4shib * opensaml * shibboleth * xerces-c * xml-security-c * xmltooling h5. Configuration The SP configuration files live in /etc/shibboleth: * shibboleth2.xml (main SP configuration file) * attribute-map.xml (defines our attribute mappings) * native.logger (configures Apache module logging -- we modify the stock configuration to log under /var/log/shibboleth instead of

Shibboleth SP

The CAMS application needs to authenticate against our IdPs, and so requires the Shibboleth service provider (SP) software to run, as well as the IdP software.

Installation

We use the stock RHEL 5 64-bit RPMs, available from the Internet2 downloads site; the current RPMs are available in the touchstone locker downloads directory. Install the following RPMs:

• log4shib
• opensaml
• shibboleth
• xerces-c
• xml-security-c
• xmltooling

Configuration

The SP configuration files live in /etc/shibboleth:

...

1. /var/log/httpd, because the apache user must have write access to the directory)

...

1. Create the directory for the native logger, and make it writable by the Apache user:

...

1. mkdir

...

1. /var/log/shibboleth/httpd

...

2. chown

...

1. apache

...

1. /var/log/shibboleth/httpd

...

1. No Format

   The Apache module will log to the native.log file in this directory.

Note: SELinux must be set to permissive mode in order for the SP to function properly; otherwise (without modifying policy) its Apache module will be unable to connect to shibd's Unix socket (which lives in /var/run/shibboleth/). Edit /etc/selinux/config accordingly.