In order to make your application use MIT Touchstone, or Shibboleth, for authentication, several steps have to be performed. MIT Information Services offers consulting services to make this process easier. However, many people at MIT are able to perform each of these simple steps with minimal intervention from IS&T.
The information below is intended to help guide you through your configuration.
Shibboleth SP version information
IS&T is currently supporting customers intending to use Shibboleth 1.3x or 2.x. We recommend that new installations use Shibboleth 2.x based SPs.
Attention
As of June 30, 2010, the Internet2 Shibboleth development team will no longer promise to supply security updates for version 1.3x. The 1.3x version will be considered end of life.
We strongly recommend that sites currently running Shibboleth 1.3 in production plan to upgrade to the current version of Shibboleth well in advance of the announced end-of-life date. This will protect against the possibility of a forced but unplanned migration from 1.3 should a security issue or incompatibility be discovered after the end-of-life date has been reached.
Using installers:
The most current installers from Internet2 can always be found at http://shibboleth.internet2.edu/downloads.html
Historical installers:
1.3x RPMs remain available from Internet2 for RHEL 4 and 5.
You will typically need the 5 main RPMs: log4shib, opensaml, shibboleth, xerces-c, xml-security-c.
You should normally skip the -devol, -debug, and -doc RPMs from the Internet2 RPM download site.
If your system does not already have curl installed, you will need to install it (via the stock RHEL RPM).
A 1.3x installer for IIS is also available from Internet2.
Some other Linux distributions also maintain binary installers available from the OS distribution point. If you have questions about other distributions please contact touchstone-support and indicate what operating distribution and version you are using.
Building from source:
The Touchstone team recommends that you use the installers available from Internet2 or your operating system vendor.
However, if you need to build from source, the Touchstone team maintains a source tarball of tbe Shibboleth SP, including all of its immediate prerequisites (curl, log4shib, xerces-c, xml-security-c, and opensaml), and a script to perform the entire build, in the touchstone locker, in /mit/touchstone/shibboleth/source/shibboleth-sp-sources.tgz.
The script can build the software on Linux and Solaris systems; note that you will to need to have Apache httpd (preferably 2.x, though 1.3 should also work) and OpenSSL (0.9.7 or higher) installed on the system, including their development packages. On Solaris systems, you must have the native Sun C/C++ compiler installed; Athena Solaris machines have this available, via attachandrun scripts and the sunsoft locker, but this requires that you have AFS tokens for the athena cell. Solaris machines must also have GNU make (gmake) installed.
To build from this, create a build directory, and unpack the source tarball into it; use the build-sp.sh script as follows: # sh build/build-sp.sh -a <apxs_path> -p <install_prefix> -s openssl_prefix
The -a option argument is the path to the Apache apxs executable, e.g. /usr/local/apache2/bin/apxs (defaults to using the apxs in the PATH). The -p option specifies the install prefix (defaults to /usr/local/shibboleth). The -s option specifies the install location of the version of OpenSSL you want to build against, e.g. /usr/local/ssl (defaults to finding OpenSSL in standard system library locations).
Once you have built the software successfully, you will need to configure and customize it for use.
Certificate request and configuration
Note: Before proceeding to "Configuration and customization for use" you should obtain a server certificate.
If your server already has a server certificate issued by the MIT Certificate Authority, and it was issued after July 1st, 2008, and it has not expired, you should be to use it with Shibboleth/MIT Touchstone. If the server certificate was issued prior to July 1st, 2008, you probably need to obtain a new server certificate.
Please make sure that you use lower case servernames in your certificate request. The server name within the certifiacte is case sensitive.
Information about how to generate a certificate request and where to send the request can be found in https://wikis.mit.edu/confluence/display/WSWG/server+certificates
Only section one of the above document is directly applicable to your configuration at this time.
*Configuration and customization for use *
Note: The gen-shib.sh procedure described below currently works only on Linux and Solaris systems; it should be portable to other UNIX-based systems without too much effort.
When you have successfully built and installed the Shibboleth SP, you will need to configure things to work against our test and pilot IdPs. We have some template files and a script in AFS (the touchstone locker) to generate the needed config files from the templates: cd to shibboleth's etc directory ($prefix/etc/shibboleth), and copy in the following files from /mit/touchstone/shibboleth/config/shibboleth-sp/ (or just copy all files from the directory):
- AAP.xml.in
- shibboleth.xml.in
- MIT-metadata.xml
- gen-shib.sh
Note: If you do not have AFS installed on your server, then you can access the above files via http, either from a browser or using wget. The URL is http://web.mit.edu/touchstone/shibboleth/config/shibboleth-sp/
On Solaris, also copy:
- shibd.in
- shibd-wrapper.in
Then run the gen-shib.sh script:
sh ./gen-shib.sh
and answer its prompts, which will hopefully be clear. Remember that the certificate it wants should be enabled for client as well as server use. Any MIT server certificates that have been created after July of 2008 will be enabled for client as well as server use.
The $prefix/etc/shibboleth directory will contain apache.config, apache2.config, and apache22.config, which contain needed and example directives for Apache 1.3, Apache 2.0, and Apache 2.2, respectively; copy and/or include the appropriate file in your Apache config, and customize as needed. The directory also contains a shibd init script for Red Hat (shibd-redhat) and Debian (shibd-debian) systems. On Red Hat machines, copy shibd-redhat to /etc/init.d/shibd, make sure it is executable, add it as a managed service with "chkconfig --add shibd", and enable it for run levels 3, 4, and 5 ("chkconfig --level 345 shibd on"). On Solaris machines, the gen-shib.sh script will generate a shibd init script (from shibd.in); this should be installed into /etc/init.d, and configured to start at boot time, after httpd has started.
NOTE: shibd is a daemon that must be running, so make sure it is started at boot time, after Apache httpd has been started.
The Shibboleth Apache module logs by default to $prefix/var/log/httpd/native.log. This file must be writable by Apache, which may require that you set its directory's ownership and/or permissions to allow write access by the user Apache is configured to run under. You may also choose to change the location of the file, by modifying the log4j.appender.native_log.fileName setting in $prefix/etc/shibboleth/native.logger.
For information on configuring Shibboleth to protect content, see the Shibboleth wiki at Internet2, as well as the information in the sections below.
You will probably also want to customize the error pages and support contact information listed in the Errors element in $prefix/etc/shibboleth/shibboleth.xml (search for "You should customize these pages!"), e.g.: <Errors session="/usr/local/shibboleth/etc/shibboleth/sessionError.html" metadata="/usr/local/shibboleth/etc/shibboleth/metadataError.html" rm="/usr/local/shibboleth/etc/shibboleth/rmError.html" access="/usr/local/shibboleth/etc/shibboleth/accessError.html" ssl="/usr/local/shibboleth/etc/shibboleth/sslError.html" supportContact="root@localhost" logoLocation="/shibboleth-sp/logo.jpg" styleSheet="/shibboleth-sp/main.css"/>
The pages are used as follows:
- session displayed if a session cannot be created after successful authentication, for example if shibd is not running. In a standard configuration, you can force this page to be displayed by visiting the server's /Shibboleth.sso location, e.g.: *https://my-sp.mit.edu/Shibboleth.sso*
- metadata displayed in certain cases where there is no valid metadata for an identity provider. This should not happen using our standard configuration; it should only be possible when using the Artifact profile, or "lazy sessions", and there is a configuration problem. You can force the page to be displayed by visiting: *https://my-sp.mit.edu/Shibboleth.sso?providerId=NoSuchIdP*
- rm displayed when an exception occurs when exporting assertions into request headers. This indicates a software problem, and should not happen.
- access displayed for access control failures. This should only happen if you have access control directives in the Apache configuration for your Shibboleth-protected content. You can force the page to be displayed by adding an access control directive that is certain to fail, for example "require NoSuchAlias" (remember to remove this configuration when you have completed testing).
- ssl displayed when a POST is attempted using http instead of https, and RedirectToSSL is in effect. This should not happen on a properly configured server.
Letting the IdP know about your application
Until the MIT Identity Providers know about your application, they won't release information about an authenticated user to your server. Each Touchstone enabled application running on a server needs to be registered with the IdPs.
To register your application server with the MIT IdPs sendmail to touchstone-support with the following information:
- A contact email address. We strongly recommend that this be an email list rather than an indivdual's persoanl email address.
- The server or host name. If you have multiple applications installed on the same server, you will actually need to register each application's provider ID. See below for more details.
- Organization name. This is typically the name of the MIT department, lab, or center running the application.
- Organization URL. The URL that provides some basic information about your department, lab, or center.
We also encourage you to send the following optional information with your registration information:
- The application URL. The actual URL which will be used to access your application.
- Your server platform. (RHEL 4, RHEL 5, Windows, Debian, Solaris, ...)
The IdP doesn't really need to know your hostname. It does need to know the Provider ID that uniquely identifies your application. Typical MIT installations that use the gen-shib.sh script (see above) hide this detail from you so that we simply need the hostname. If you want to learn more about provder ID naming please see EntityNamingat the Internet2 wiki site.
A single Shibboleth SP installation is designed to support multiple applications installed on that server, but there are different deployment and configuration strategies to support multiple applications. At MIT we recommend that each application be configured to use a separate Apache vhost, in addtion to simply creating additional ProviderIDs for each application. More information is available here: Shib 1.3 Add Separate Application.
Keep your metadata up to date
You should ensure that your SP's copy of the MIT metadata is kept up to date. The current metadata is available in http://web.mit.edu/touchstone/shibboleth/config/metadata/MIT-metadata.xml.
The easiest way to maintain the metadata is via a cron job which runs a script to download and install the latest metadata. A sample of such a script is available in http://web.mit.edu/touchstone/shibboleth/config/metadata/update-metadata.sh-example. Adjust it as necessary for your installation; in particular, if you did not install from the stock RPMs from Internet2, you will need to adjust the setting for the Shibboleth etc directory at the top of the script.
The Shibboleth SP software detects and loads the updated metadata automatically; there is no need to restart the web server or shibd.
Example code and configuration information for third party applications
We have some pointers to example code written in various lanaguages. We do expect the examples to increase over time. We are also creating some local documentation that covers the configuration of third party software. However, users are encouraged to look at resources outside of MIT as well. If you do find useful information please do bring it to our attention.
Some simple examples:
- Display the results of the SAML assertion in various languages.
Third party applications:
- Drupal*Support Resources*Consulting Services:
Consulting service may be arranged by sending mail to touchstone-support. This will open an RT case and a person will be assigned to work with you.
Training:
We are intending to offer some hands on training during IAP 2009. Space will be limited to 18 participants. The hands-on lab is scheduled for January 20th, 1:30-3:30pm. There will also be session talking about configuration options on January 16th, from 2:30-4:00pm.
Who to Contact:
