Page History

...

Panel

Tip
Before proceeding to "Configuration and customization for use" you should obtain a 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.ezproxyberklee.flo.org/confluence/display/WSWG/How+to+acquire+and+verify+a+M.I.T.+x509+Server+Certificate

Note

Historical note:

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 able 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.

Configuration and customization for useConfigure the SP software

Panel

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.ezproxyberklee.flo.org/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.

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://mv-ezproxy-com.ezproxyberklee.flo.org/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://mv-ezproxy-com.ezproxyberklee.flo.org/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.
Note
title Historical information
Configuring and customizing the Shibboleth 1.3x SP

Customize the error pages

Configuring and customizing the Shibboleth 1.3x SP

Panel

Tip
This is optional, but recommended.

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

Code Block


<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://mv-ezproxy-com.ezproxyberklee.flo.org/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://mv-ezproxy-com.ezproxyberklee.flo.org/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.

Note

title	Historical information

Letting the IdP know about your application

...

Child pages

Versions Compared

Old Version 26

New Version 27

Key