Page History

...

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

  No Format
  # cd /tmp # rm -rf shibboleth-identityprovider-2.* # tar xzf /path/to/mit-shibboleth-identityprovider-2.1.5-bin.tgz # cd shibboleth-identityprovider-2.1.5 # ./install.sh [There should be no need to override the default responses to the installer's questions.]

  By default (because of one of our customizations to the stock Internet2 distribution) this will install 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 zip file, plus the following customizations:
  • MultiAuthnOptionLoginHandler
    This our custom login handler extension, which supports multiple authentication options (certificate, username/password, etc.). The current jar file for the extension is available in the locker, in /mit/touchstone/builds/NIST/shibboleth-idp-ext-MultiAuthnOptionLoginHandler-<version>.jar, where <version> is 1.0 for idp version 2.1.x, and 1.1 for idp version 2.3.x; it is copied into the lib/ subdirectory of the binary distribution.
  • mitlogin
    This provides the custom login pages for MIT users, the web deployment descriptor, etc. It is available as a tarball (/mit/touchstone/builds/NIST/idp2-mit/mitlogin.tgz) which is unpacked into the top-level directory of the binary distribution.
  • MySQL connector
    This is needed for accessing our targeted ID MySQL database. The connector is available in /mit/touchstone/downloads/mysql-connector-java-5.1.NN-bin.jar (current version is 5.1.14).
  • rhino-1.7R1.jar
    This is an updated version of the Rhino Javascript package, patched locally to disable the Javascript optimizer, which had caused a memory leak when using terracotta for clustering. The patched version is available in /mit/touchstone/builds/NIST/rhino-1.7R1.jar.
• 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).
• 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.:

  No Format
  # chown -R tomcat:tomcat /usr/local/shibboleth-idp

  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/:

  No Format
  # cp /path/to/idp.war /usr/local/tomcat/webapps/ # chown tomcat:tomcat /usr/local/tomcat/webapps/idp.war

• Copy the idp's endorsed jar files to tomcat's endorsed dir:

  No Format
  # mkdir -p /usr/local/tomcat/endorsed # cp -p /usr/local/shibboleth-idp/lib/endorsed/*.jar /usr/local/tomcat/endorsed/ # chown -R tomcat:tomcat /usr/local/tomcat/endorsed

• Copy in the idp config files for the server, to the conf subdirectory (they are available in /mit/touchstone/config/idp2-core/shibboleth-idp/); these include:
  • attribute-filter.xml
  • attribute-resolver.xml.in
  • authn-config.properties
  • handler.xml
  • internal.xml
  • logging.xml
  • login.config
  • relying-party.xml
  • service.xml
  • tc-config.xml (for terracotta clustering)
    You must replace %%LDAPUID%% and %%LDAPPASSWORD%% in attribute-resolver.xml.in with the principal uid (e.g. touchstone-core-service) and passord (principalCredential attribute) for accessing our LDAP server, and save the resulting file as attribute-resolver.xml. Make sure the file is not world-readable.

Terracotta

(See https://wiki.shibboleth.net/confluence/display/SHIB2/IdPCluster^{Image Removed})

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.

...

For more information on maintaining the IdP cluster, see https://wikis-mit-edu.ezproxy.canberra.edu.au/confluence/display/TOUCHSTONE/Maintaining+the+terracotta+cluster+on+the+IdPs^{Image Removed}

Targeted ID MySQL database

...