Versions Compared

Old Version 45

changes.mady.by.user Robert A Basch

Saved on

compared with

New Version Current

changes.mady.by.user Robert A Basch

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

This page is under construction

Executive Summary

Version 2 of the MIT core identity provider is based on version 2.1.x of Internet2's Shibboleth IdP package. Including the IdP software itself, the following major components are required:

  • Apache httpd 2.2 (from stock RHEL httpd RPM)
  • mod_ssl (from stock RHEL mod_ssl RPM)
  • Tomcat 6.0
  • JDK 6.0 (from Sun, plus enhanced JCE and security policy)
  • Shibboleth IdP 2.1
  • terracotta 3.1
  • MySQL 5.0 (from stock RHEL RPMs)
  • Shibboleth SP 2.3.x (from Internet2 RPMs)
  • Cams web application
  • cams-ldap (CAMS/LDAP integration)

In the configuration documented below, the Apache web server will listen on the following TCP ports:

  • 80 (HTTP)
  • 443 (SSL virtual host for HTTPS)
  • 8443 (SSL virtual host for SP's back-channel SOAP calls for attributes)

The terracotta server will listen on the following TCP ports (connections should only be allowed from the peer node(s)):

  • 9510 (client-to-server)
  • 9520 (JMX)
  • 9530 (server-to-server)

The MySQL server will listen on the following TCP port:

  • 3306

Note that the terracotta and MySQL listeners only need to accept connections from peer servers in the cluster, so these ports should be configured accordingly in the firewall.

The following certificates/keys need to be created:

  • MIT SSL server certificate (CN idp.mit.edu)
  • daemon keytab (i.e. daemon/idpe.mit.edu@ATHENA.MIT.EDU)
  • application client certificate (CN touchstone-cams.app.mit.edu)

The following log files will be used:

  • Apache httpd log files in /var/log/httpd/:
    • ssl_access_log
    • ssl_request_log
    • ssl_error_log
    • idp-attr-query_access_log
    • idp-attr-query_request_log
    • idp-attr-query_error_log
    • access_log
    • error_log
  • Shibboleth IdP log files in /usr/local/shibboleth-idp/logs/:
    • idp-process.log
    • idp-access.log
    • idp-audit.log
  • Tomcat logs in /usr/local/tomcat/logs/
    • catalina.out
  • terracotta system logs in /usr/local/terracotta/logs/:
    • terracotta.log
    • run-dgc.cron.log
  • terracotta cluster logs in /usr/local/shibboleth-idp/cluster/:
    • client/logs-127.0.0.1/terracotta-client.log
    • server/logs/terracotta-server.log

SELinux

SELinux must run in Permissive mode. Otherwise, the Shibboleth SP Apache module will not be able to connect to the shibd socket, and mysqld will not be able to load in the shared library used by cams-ldap.

...

Make sure that the additional port used by the IdP are enabled in the firewall. Use the command "iptables --list -n --line-numbers" to determine the proper rule number; the following example assumes we are inserting rules beginning at number 36. Also replace 18.x.y.z with the appropriate IP address of the peer node in the cluster, not the local host.

No Format

# iptables --list -n --line-numbers
# iptables --list -n --line-numbers
# iptables -I RH-Firewall-1-INPUT 36 -m state --state NEW -m tcp -p tcp --dport 8443 -j ACCEPT
# iptables -I RH-Firewall-1-INPUT 3637 -m state --state NEW -m tcp -p tcp -s 18.x.y.z --dport 84433306 -j ACCEPT
# iptables -I RH-Firewall-1-INPUT 3738 -m state --state NEW -m tcp -p tcp -s 18.x.y.z --dport 33069510 -j ACCEPT
# iptables -I RH-Firewall-1-INPUT 3839 -m state --state NEW -m tcp -p tcp -s 18.x.y.z --dport 95109520 -j ACCEPT
# iptables -I RH-Firewall-1-INPUT 3940 -m state --state NEW -m tcp -p tcp -s 18.x.y.z --dport 9530 -j ACCEPT
# /etc/init.d/iptables save

...

  • To support additional cryptographic algorithms used by the IdP, download and install the Bouncy Castle JCE jar file (http://polydistortion.net/bc/index.html) in the lib/ext directory of the JRE (/usr/java/latest/jre/lib/ext/). For example:
    No Format
    # cd /usr/java/latest/jre/lib/ext
# cp /path/to/bcprov-jdk16-145.jar .
    (Replace the file version number as needed).
    Add it as a provider in in the JRE's lib/security/java.security, e.g.:
    No Format
    security.provider.9=org.bouncycastle.jce.provider.BouncyCastleProvider
    (Replace 9 with the next sequential provider number as needed).
  • We want to ensure that DNS lookups are not cached indefinitely. Set the networkaddress.cache.ttl property in java.security accordingly:
    No Format
    
networkaddress.cache.ttl=30
  • To support use of crypto key sizes larger than 2048 bits, we also add the Unlimited Strength Security Policy to the JVM. Download jce_policy-6.zip from the locker downloads directory, or from Sun (http://java.sun.com/javase/downloads/index.jsp, Other Downloads section at the bottom). Unzip the policy zip file and copy local_policy.jar and US_export_policy.jar into the JRE's lib/security directory (replacing the versions installed from the JDK RPM).
    No Format
    # cd /tmp
# unzip /path/to/jce_policy-6.zip
# cd jce
# cp *.jar /usr/java/latest/jre/lib/security/

...

Make sure the daemon starts at boot time:

No Format


# chkconfig mysqld on

We use master/slave replication, 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.

...

Make sure that connections are allowed to port 3306 from the peer server only (see firewall instructions above). For instructions on setting up the MySQL master/slave replication, see https://wikis-mit-edu.ezproxyberklee.flo.org/confluence/display/ISDA/MySQL+Replication+Configuration+InstructionsImage Removed

Maintaining the CAMS database

...

  • 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:
    No Format
    # cd /tmp
# rm -rf shibboleth-identityprovider-2.*
# tar xzf /path/to/cams-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, from the Internet2 zip file (http://shibboleth.internet2.edu/downloads/shibboleth/idp/latest/Image Removed), plus the following customizations:
    • 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.
    • CamsLoginModule (cams-jaas-loginmodule-x.y.jar)
      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.
    • camsutil-1.0.jar
      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.
  • 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; these include:
    • attribute-filter.xml
    • attribute-resolver.xml
    • handler.xml
    • internal.xml
    • logging.xml
    • login.config
    • relying-party.xml
    • service.xml
    • tc-config.xml (for terracotta clustering)

Terracotta

(See https://spaces.internet2.edu/display/SHIB2/IdPClusterImage Removed)

The terracotta software is can be used to cluster the IdP nodes. Note that currently the Cams IdPs are not clustered, so terracotta should not be running. 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.

...

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:

...

as the IdP software.

Installation

We use the stock RHEL 5 64-bit RPMs, available from the Internet2 downloads site; the best way to install the RPMs is to use Shibboleth's yum repository, as described in https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPLinuxRPMInstall. To configure the repository, install the repository definition file into /etc/yum.repos.d. Once the repository is configured, you can install the current RPMs, including dependencies, using yum, e.g.:

No Format

# yum install shibboleth.x86_64

...

Configuration
The SP configuration files live in /etc/shibboleth:
...