Common Error Messages
Unable to locate metadata for identity provider (https://idp2.shib.umn.edu/idp/shibboleth)
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 need to add the additional ACS URLs for your virtual hosts and send us the updated metadata to load. 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
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.
Incorrect username or password when logging into the test IdP
The test IdP uses the test X.500 directory, which does not contain everybody that the production directory does. Contact Identity Management to request that we copy your test users from production to test.
Error resolving attributes
Indicates directory lookup failure on the IdP side. Either the user is not in the test directory (if test), or the test directory is malfunctioning. This usually happens if you have logged into CAH in production, then try to authenticate against the test IdP when your entry is not in the test X.500 directory.
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 Shib 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.
How to add more servers (virtual or real) to metadata
Following the steps in the Shibboleth Self-Help Guide, create metadata with multiple servers. Whenever you add or remove servers, send us your updated metadata file and we will load it into the IdP for you.
Test IDs for vendors
We recommend requesting departmental accounts for vendors who want to test Shibboleth authentication.
If you are using SAML version 2 (the usual case), you do not need to make any firewall changes to account for Shibboleth. All interaction between the IdP and SP is via the browser.
If you are using SAML version 1, your SP will need to be able to make outbound connections on TCP port 8443 to the IdP in order to fetch attributes.