Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Configure the SP software for Touchstone

Panel

On a Linux server, the quickest way to get started is to copy the following files from the Touchstone locker (/mit/touchstone/config/shibboleth2-sp) into /etc/shibboleth:

  • attribute-map.xml
  • gen-shib2.sh
  • shibboleth2.xml.in

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/config/shibboleth2-sp/

Then run the gen-shib2.sh script, and answer the prompts, to generate shibboleth2.xml. For example:

No Format
# cd /etc/shibboleth
# cp /mit/touchstone/config/shibboleth2-sp/* .
# sh gen-shib2.sh

Note that any changes to the shibboleth2.xml, attribute-map.xml, and attribute-policy.xml files will be detected automatically, i.e. without requiring a restart of shibd.

Note: The gen-shib2.sh procedure described above is currently supported on Linux systems only; it should be portable to other UNIX-based systems with minimal effort. Please contact touchstone-support if you are using another operating system and having problems with the gen-shib2.sh script.

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. The current Red Hat RPMs also install the init script into /etc/init.d/shibd, and adds it as a managed service.

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.

On Windows/IIS machines, the shibboleth2.xml.windows-example file in the locker is a good starting point for the shibboleth2.xml file. You will need to edit the file for it to work on your server; please see the comments at the top of the file for the details. The attribute-map.xml file in the locker should work without modification.

...

Panel
Info

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, by our adding it to metadata.

Tip

To register your application server with the MIT IdPs send mail to touchstone-support with the following information:

  • A contact email address. We strongly recommend that this be an email list rather than an individual's personal email address. Note that this address will be published in the MIT metadata file.
  • The server or host name. This should be the web server host name, i.e. the host name that a user would specify when entering the URL to access your site. This should be the same as the Subject CN in your server's SSL certificate, and match the host name entered in response to gen-shib2's initial prompt. This name will be used to create a unique Entity ID by which the IdPs will identify your SP; by convention, this ID is the URI https://mywebapp.mit.edu/shibbolethImage Added. (For more information on entity ID naming, please see EntityNaming|https://wiki.shibboleth.net/confluence/display/SHIB2/EntityNaming]at the Internet2 wiki site). If you have multiple applications installed on the same servermachine, served by different host names (e.g. using different Apache vhosts), you will actually also need to register provide each application's provider ID. See below for more detailshost name, as Shibboleth endpoints on each host must be registered in metadata. In some cases, different applications will require the use of separate entity IDs; please see below.
  • The certificate information for the SP. If using the self-signed certificate generated at install time, you must include the certificate itself (in /etc/shibboleth/sp-cert.pem); do not send the private key file. If using the MIT server SSL certificate, we only need the Subject CN from the certificate (should be the same as the web server host name above).
  • 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 machine's host name(s), if different from the web server host name.
  • 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 Entity 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 entity 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 simply be configured to use a separate Apache vhost; more complex configurations, e.g. creating separate entity IDs for each application, are also possibilepossible. More information is available hereFor more information, please see:

An example of when separate entity IDs are needed would be if one application requires a non-standard set of attributes to be released to it. Please consult with touchstone-support as needed.

Testing your Shibboleth configuration

...