Table of Contents

Overview

The Shibboleth Service Provider consists of two parts: the shibd process and a web server plugin.

Shibd

Shibd is a background process that handles requesting authentication and processing attributes from the IdP. It is called for each web request to verify authorization and populate environment variables with the attributes provided by the IdP. By passing the attributes as environment variables the web application is able to access them.

Web server plugin

The web server plugin for Apache is mod_shib. On IIS it was implemented as an ISAPI filter in SP v2 instead of using native calls. The module/filter communicates with the shibd process to validate authorization and access attributes.

Installation

Install on Linux
Install on Windows
Install on macOS

Configuration

Default install directory

• Windows - C:\opt\shibboleth-sp
• Linux/UNIX/Solaris - /etc/shibboleth

Relevant files

• shibboleth2.xml - Main configuration file where the IdP, session settings, and authorization rules are defined
• attribute-map.xml - Defines how to map attributes received from the IdP to names usable by the web application

Log directories

• Windows - C:\opt\shibboleth-sp\log

• Linux/UNIX/Solaris - /var/log/shibboleth

Keys

Generate keys - If Shibboleth was installed using a package, keys should have been automatically generated. By default they are in the configuration directory and named sp-cert.pem and sp-key.pem. If the keys do not exist they can be generated by running keygen.sh or keygen.bat.
NOTE: The SP's private key is stored in sp-key.pem. The private key should be protected and only readable by the shibd user.

Configuration specifics

Configuration files

• Replace the existing files in the configuration directory:
  shibboleth2.xml

  This file is not recommended for use with Version 3 of the Shibboleth SP software.

  
  attribute-map.xml (Not yet available)

• Add the RIT metadata to the configuration directory.
  rit-metadata.xml

Customize shibboleth2.xml to your site/application

• Change references to sp.example.org to the public hostname of your server. For example, if the server is named server1.example.org but users access myapplication.example.org then use myapplication.example.org.

• If an attribute different than uid (username) is required for REMOTE_USER change it. (See below.)

  <ApplicationDefaults entityID="https://sp.example.org/shibboleth" REMOTE_USER="emailAddress" signing="true" encryption="true">
  

• If using IIS, configure the InProcess configuration block. (More information)
• Adjust the session lifetime and timeout as necessary. (NOTE: The times are in seconds.)
• Modify the supportContact value.

Configure protection

• The RequestMap element controls what URLs of the website need to be protected. This can be done at any point in the path and can also include authorization rules.
• A detailed explanation of this configuration element is available on the Shibboleth wiki.

Verify functionality

• Restart the Shibboleth service and web server.
• Navigate to https://yourhostname.example.com/Shibboleth.sso/Metadata. If it gives an error, you do not see the metadata, or there are references to sp.example.com there is a misconfiguration.

Troubleshooting

Please contact ITS for assistance with troubleshooting issues.