Access: Shibboleth FAQ

This page documents some of the most common issues and troubleshooting steps for Shibboleth integration.

Common Error Messages

Unable to Locate Metadata for Identity Provider (https://login.umn.edu/metadata.xml)

  • Make sure you loaded our IdP metadata correctly – check the MetadataProvider element(s) in your shibboleth2.xml file.
  • Note that you can load metadata for more than one IdP by using multiple MetadataProvider elements.

Unknown Application Error (was SAML 2 SSO profile is not configured for relying party)

  • Our IdP does not have the metadata for your SP loaded, or the entityID in the metadata does not match the entityID your SP is using.

Application Configuration Error (was No peer endpoint available to which to send SAML response)

  • Our IdP has metadata for your SP loaded, but your metadata does not have valid AssertionConsumerService endpoints for the virtual host you're using.
    • You'll either need to add the additional ACS URLs for your virtual hosts and send us the updated metadata to load, or enable request signing.
    • Follow the steps in the Shibboleth Self-Help Guide for how to create metadata with multiple servers.

opensaml::FatalProfileException - A valid authentication statement was not found in the incoming message

  • There are a couple possible reasons for this error.
    • One cause is if the SAML encryption key used by your SP (typically sp-cert.pem and sp-key.pem in the same directory as shibboleth2.xml) does not match the encryption key in the metadata the IdP has for your SP.
      • Update the key on the server so it corresponds to the metadata, or send us new metadata with the correct key included.
        • One way this can happen is if you add a new server to the metadata for an existing entityID, but you don't copy over the encryption key files from the existing server to the new one.
      • All servers using the same entityID must use the same encryption key.
    • Another reason is if certain error conditions occur on the IdP side.
      • You'll usually see a "Responder" code at the bottom of the error page if this happens.
      • To determine the specific error, contact Technology Help and let us know the date and time the error occurred (copying and pasting the full error message is a good way to do this). We can check our logs and advise how to proceed.

Error Resolving Attributes

  • Indicates LDAP directory lookup failure on the IdP side. This is typically a transient error message, and retrying will succeed. If it persists, please let us know. 

Message Did Not Meet Security Requirements

  • This can have a variety of causes, and you'll have to ask us to look in the IdP logs to identify what specifically went wrong.
  • One common cause is if your server's clock is off by more than a couple of minutes.
  • Check to be sure your server's time synchronization (e.g. ntpd) is working.

Links in Office Documents

  • If you have a Microsoft Office document that links to a Shib-protected web page, users may get errors from Shibboleth.
    • The reason for this is that Office follows redirects internally and only hands off the final link to the browser, which results in the loss of critical state information Shibboleth needs to function.
    • This Microsoft Knowledge Base article explains the problem from their point of view. They also link to a workaround via the registry.

Test IDs for Vendors

Firewall Configuration

  • You do not need to make any firewall changes to account for Shibboleth. All interaction between the IdP and SP is via the browser.

Last modified

Changed

TDX ID

TDX ID
5975