Skip to end of metadata
Go to start of metadata

Purpose

This page describes Shibboleth Service Provider (SP) configuration necessary to download the UW Identity Provider (IdP) local metadata file and, optionally, verify the digital signature.

Background

The UW is part of the InCommon federation and publishes its IdP metadata in the InCommon metadata aggregate (http://md.incommon.org/InCommon/InCommon-metadata-idp-only.xml). However, the InCommon metadata aggregate has grown large enough to cause problems for SPs when they attempt to download the file and verify the digital signature. Symptoms include high memory utilization, very slow restarts, and occasional failures to restart the shibd process.

To mitigate these issues, InCommon now provides a Per-Entity Metadata Service that queries for the specified IdP and caches frequently called IdPs.  This service, also know as MDQ (based on the IETF "Metadata Query" protocol), is available at https://mdq.incommon.org.  Please see Configure a Shibboleth SP to use the InCommon Per-Entity Metadata Distribution Service for more information about this service.  Note: some Service Providers are unable to consume a multi-entity metadata aggregate mandating the use of UW IdP metadata.

For Service Providers who wish to consume a small, static metadata file, the UW IdP publishes a local copy of its metadata and digitally signs the file. The sections below describe the SP configuration necessary to download the local metadata file and (optionally) verify the digital signature. If the local IdP metadata is downloaded from https://idp.u.washington.edu/metadata/idp-metadata.xml, the HTTPS protocol provides integrity and signature verification is optional (but recommended). If the IdP metadata is obtained from other sources, the digital signature should be verified. If signature verification will be used, the SP must keep a copy of the IdPs signing certificate in its configuration. 

SP Configuration

Warning

SPs that are federated to accept users from other (non-UW) InCommon IdPs should not use this configuration. They will require the InCommon Per-Entity Metadata Service located at (https://mdq.incommon.org/). The configuration described below is intended for SPs that rely only on the UW IdP.  For more information see Configure a Shibboleth SP to use the InCommon Per-Entity Metadata Distribution Service.

1. Add the MetadataProvider element

  • Open your shibboleth2.xml file for editing.
  • Find the section with MetadataProvider elements.
  • Add the following MetadataProvider:

    <MetadataProvider type="XML" url="https://idp.u.washington.edu/metadata/idp-metadata.xml" 
    		backingFilePath="idp-metadata.xml" reloadInterval="7200">
    		<MetadataFilter type="Signature" certificate="uw-idp-md-cert.pem"/>
    </MetadataProvider>
  • The MetadataFilter element says that the signature on idp-metadata.xml should be verified using the uw-idp-md-cert.pem certificate.

  • If you don't intend to validate the signature, omit the MetadataFilter element.
  • If you have configured a MetadataProvider for the InCommon metadata aggregate, you should comment it out or delete it.

  • Save your shibboleth2.xml file.

2. Install the UW IdP signing certificate

  • Complete these steps if your SP will verify the digital signature on UW metadata.
  • The UW IdP signing certificate is attached to this page. Download it to your SP (in the upper right of this page, Tools menu (with the ... symbol) > Attachments).
  • Save the certificate file in the same directory as your shibboleth2.xml file. Name it something like uw-idp-md-cert.pem
  • This signing certificate is identical to the one included in the UW section of the InCommon metadata aggregate.

3. Restart the shibd process

  • Restart the shibd process on your SP however you normally do that on your platform.
  • This will cause Shibboleth to check the MetadataProvider locations and to download any updates. Shibboleth will also verify the digital signatures on any metadata where it is configured to do so. 

4. Verify success in the logs

  • The restart of shibd, reloading of metadata, and signature verification should all be recorded in shibd.log.
  • Open the log file and scroll to near the bottom of the file to find messages from the shibd restart.
  • Look for messages like the following (numbering added for clarity, these are not present in the log file):

    1. 2018-03-23 12:05:16 INFO OpenSAML.Metadata.Chaining : building MetadataProvider of type XML
    2. 2018-03-23 12:05:16 INFO OpenSAML.Metadata : building MetadataFilter of type Signature
    3. 2018-03-23 12:05:16 INFO XMLTooling.SecurityHelper : loading certificate(s) from file (C:/opt/shibboleth-sp/etc/shibboleth/uw-idp-md-cert.pem)
    4. 2018-03-23 12:05:16 INFO XMLTooling.CredentialResolver.File : no private key resolved, usable for verification/trust only
    5. 2018-03-23 12:05:17 INFO OpenSAML.Metadata.XML : loaded XML resource (https://idp.u.washington.edu/metadata/idp-metadata.xml)
    6. 2018-03-23 12:05:17 INFO OpenSAML.Metadata : applying metadata filter (Signature)
    7. 2018-03-23 12:05:17 INFO OpenSAML.Metadata.XML : adjusted reload interval to 7200 seconds
    8. 2018-03-23 12:05:17 INFO OpenSAML.Metadata.XML : reload thread started...running every 7200 seconds
  • Message #3 indicates that the certificate file on disk was successfully loaded (this will be present only if the SP is configured to load the IdP signing certificate).
  • Message #5 indicates that the local UW IdP metadata file was successfully loaded.
  • Message #6 indicates that the signature on the metadata file was successfully verified (this will be present only if the SP is configured to verify the digital signature). 
  • If instead you see warning or errors for these entries, go back and verify you have followed these instructions.

References



  • No labels