IAM in Service Catalog
Shibboleth Service Provider 3.1.0 is the current version. No previous versions are supported by the Shibboleth Consortium.
This document describes the procedure used to install Shibboleth Service Provider (SP) software on Windows Server and Internet Information Server (IIS), and to configure it to work with the UW Identity Provider (IdP). The instructions support a basic install for a single web site and application, authenticating users with their UW NetID. More advanced configuration topics will be covered separately.
The reader should have prior Windows Server and IIS system administration experience. The ability to read and edit XML files with a text editor is required to configure the software.
The IIS website must have an appropriate x509 certificate installed and SSL enabled. Shibboleth Service Provider 3.x software supports Windows Server 2008 and later, and installers are available for both 32-bit and 64-bit systems. Shibboleth 3.x supports the versions of the IIS web server that are provided with the supported Windows versions. For upgrades from version 2.x, a legacy ISAPI module is provided for compatibility but will be discontinued in a future version, and the new IIS native module should be used instead. (See note at the bottom of this page)
1.1 Download the latest version of the Windows installer package from the Shibboleth download site at https://shibboleth.net/downloads/service-provider/latest/. Select either the win32/ or win64/ directory as appropriate to your 32-bit or 64-bit system. These instructions were tested as follows:
1.2 Run the installer package. It is recommended that you accept all defaults, as follows:
2.1 On the Administrative Tools menu, click Services. Find Shibboleth 2 Daemon in the list and double-click it. Verify that Service Status is Running, Startup type is Automatic, and on the Log On tab, verify that Local System is selected.
2.2 Verify the configuration is generally valid by running the code below from the command line:
If the last line of the output is the following message, everything is as expected:
If there are any ERROR messages, we strongly recommended you resolve them. Messages with log level WARN are generally not problematic but should be noted and re-investigated after configuration steps are complete.
If you experience startup problems, you should do the following:
The UW is part of the InCommon federation and publishes its IdP metadata in the InCommon metadata aggregate. The best way to consume this metadata is via the InCommon Per-Entity Metadata Distribution Service. However, the InCommon Per-Entity Metadata Distribution Service is not appropriate for all SPs, especially Service Providers that are unable unable to consume a multi-entity metadata aggregate. To avoid these problems, the UW IdP publishes a local copy of its metadata and digitally signs the file. SPs that are federated to accept users from other (non-UW) InCommon IdPs should not use this metadata, and should use the InCommon Per-Entity Metadata Distribution Service.
3.1 If your SP will rely only on the UW IdP for user authentication, skip steps 3.2 and 3.3 and install the UW IdP metadata signing certificate instead. See UW IdP Metadata for instructions and certificate download. If your SP will rely on other IdPs from InCommon, continue on at step 3.2.
3.2 The MDQ signing certificate is here. Depending on your OS and browser, the certificate might be displayed in the browser or you might be asked to save the file.
3.3 Save the file to
Save a copy of
shibboleth2.xml.orig or similar then open
shibboleth2.xml in a text editor. Type carefully; one of the biggest sources of problems is typos made in this file.
4.1 Find <ISAPI...>...<Site id="1" name="sp.example.org"/>. Change the site id to match the id assigned to your site by IIS. The site id will be 1 for the default web site. You can find your site id in Internet Services (IIS) Manager by clicking on "Sites".
In this same location, change the name to your DNS name (e.g. myserver.mydept.washington.edu). Go ahead and put your DNS name in your paste buffer because you'll need to enter it twice more.
Verify that scheme="https" and port="443". Note that if you're using a non-standard SSL port you should use that instead of 443.
4.2 Find <RequestMap>...<Host name="sp.example.org">. Change the name to your DNS name.
4.3 Find <ApplicationDefaults entityID=""...>. Replace with something based on your DNS name (e.g. ).
4.4 Find <ApplicationDefaults...>...<Sessions...>...checkAddress="false" handlerSSL="false" cookieProps="http"> ...Change to checkAddress="true" handlerSSL="true" cookieProps="https">
If you are using DNS proxy, such as Amazon Route 53, you may receive a "500 - Internal server error." when testing. This is caused by the client's IP address differing from the one used to authenticate to the identity provider. The work around is to set checkAddress="false" instead of "true"; while useful for security, NAT and proxy usage (as well as IPv6 support on only either the webserver hosting the IdP or the SP) often make this setting a source of errors.
4.5 Find <ApplicationDefaults...>...<Sessions...>...<SSO entityID="https://idp.example.org/shibboleth"...>.... Change the entityID to "urn:mace:incommon:washington.edu" (just "urn:mace:incommon:washington.edu" NOT" "). Remove discoveryProtocol="SAMLDS" discoveryURL =" https://ds.example.org/DS/WAYF ".
4.6 Find < Errors supportContact ="root@localhost" helpLocation ="/about.html" styleSheet ="/shibboleth-sp/main.css" /> and change the email address to your application's support email address.
4.7 Find the <MetadataProvider...>...</MetadataProvider> section and un-comment the metadata type you'll be using by removing the <!-- and --> tags that surround it.
4.8 If your SP will rely only on the UW IdP for user authentication, skip steps 4.9 and 4.10 and follow instructions at UW IdP Metadata. If your SP will rely on other IdPs from InCommon, continue on at step 4.9.
4.9 If your Service Provider will be configured to accept users from other (non-UW) InCommon IdPs, follow the instructions at Configure a Shibboleth SP to use the InCommon Per-Entity Metadata Distribution Service to add the MDQ metadata.
4.10 Save shibboleth2.xml and close your editor.
4.11 Use Internet Services (IIS) Manager to restart IIS and Administrative Tools > Services to restart the Shibboleth 2 Daemon.
4.12 Restart the web server and the access the URL from the server's browser: https://<your dns name>/Shibboleth.sso/Session . The web server should return a page that says:
This message demonstrates that the Shibboleth module is loaded by the webserver and is communicating with the
4.13 Download your SP metadata from https://<your dns name>/Shibboleth.sso/Metadata. Depending on your OS and browser, the metadata might be displayed in the browser or you might be asked to save the file. If you save the file with a
.xml file extension and open the file in your browser it will be easier to read. Make sure there are no instances of sp.example.org in the URLs; any such references should have been replaced by your DNS name. The file will contain a warning about reviewing the contents of the file and not supplying it in real time–that's normal. Checking for sp.example.org counts as review, and our registry doesn't monitor the contents of that file after the initial registration (i.e. not real time).
5.2 It will take a few minutes for your registration to propagate to the UW IdP before you can begin testing. See Flow of Metadata and Filter Policies from SP Registry to the IdP for the current schedule.
At this point you should have a basic installation of Shibboleth that works with IIS. There are a few quick tests you can do to verify this. Note that there are potentially many more configuration changes you will need to make to integrate Shibboleth with your application and get it ready for production use. Those topics are outside the scope of this document and will be covered elsewhere.
6.1 As configured, Shibboleth will not yet be protecting your web site. To verify this, use your browser to request a document from the root of your web site. The document should be returned without being redirected through the UW IdP for authentication.
6.2 By default, Shibboleth is configured to protect content in a directory named
/secure in the root of your web site. Most likely that directory doesn't exist. To do a quick test that Shibboleth is working as expected, create
/secure in the root of your web site (not in the IIS install root directory) and add a sample document. When you request that document with your browser you should be redirected through the UW IdP to the UW NetID sign-in page. Sign in with your UW NetID and the sample document should be returned to you.
6.3 While still signed in, open a new tab and point your web browser to https://<your dns name>/Shibboleth.sso/Session and review the response. Your browser should return a status page similar to this:
Refer to the documents on the Shibboleth Service Provider Support page for help with the rest of your Service Provider configuration. Be sure to subscribe to the Shibboleth Project's announcement list. This is a low traffic list used to announce new releases and security advisories.
Existing 2.x installations configured to work with IIS will continue to do so, but require the older ISAPI plugin to be updated. See this topic for details, particularly about migrating to the newer plugin.