Shibboleth FAQs

Frequently (or at least occasionally) asked questions relating to the use of Shibboleth by web servers within the University of Cambridge, intended largely for the people responsible for running those web servers. This page isn't intended to cover questions from people about how they identify themselves with Shibboleth.

SSO profile is not configured for relying party

As from June 2012 the Raven shibboleth server only provides authentication services to SPs it knows about - i.e. SPs that have registered with the 'UK federation' of the local 'Ucam federation'. Trying to use the Raven IdP from an unregistered SP, or from one whose configuration does not match the metadata that has been registered with the federations, will result in error messages like:

SAML 2 SSO profile is not configured for relying party <entityID>

or

Shibboleth SSO profile is not configured for relying party <entityID>

or

 Message did not meet security requirements

'Invalid assertion consumer service URL' or 'No peer endpoint available to which to send SAML response'

When I try to authenticate I get an error page from Raven (or some other IdP) containing the text "Invalid assertion consumer service URL" or "No peer endpoint available to which to send SAML response".

When an SP registers in the UCam or UK federation it supplies SP Metadata which includes a list of the URLs (in one or more <md:AssertionConsumerService> (ACS) elements) to which IdPs are allowed to return information. When an SP makes an authentication request it can specify which ACS URLs it wants the results returned to on this occasion. This message means that the URLs in the request don't not match any of those in the metadata. Despite the message being reported by the IdP, it normally reflects a problem on the SP.

The most common cause of these error message is accessing an SP over http that also supports https and which has only registered https assertion consumer service URLs. Further details for this problem, and a number of suggested solutions are available in SP Metadata.

The problem can also just represent a mismatch between the SP configuration and the registered metadata - this might happen, for example, if the SP was reconfigured after a copy of its metadata had been created. It can also happen if a server hosts multiple sites (virtual hosts) but the SP has not been configured with this in mind (see Virtual hosting issues with Shibboleth).

"Identity provider lookup failed" and/or "Security of SAML 1.x SSO POST response not established"

When I try to authenticate I get an error page from my SP containing the text "Identity provider lookup failed!" and/or "Security of SAML 1.x SSO POST response not established"

"Identity provider lookup failed" probably means that your SP does not have access to metadata describing the IdP you are trying to use. This will inevitably lead to "Security of SAML 1.x SSO POST response not established", since the metadata carries the information needed to establish this security, but this latter message can occur by itself under other circumstances.

Check the <MetadataProvider> elements in shibboleth2.xml - you should expect to have one with a 'uri=' attribute of

 https://shib.raven.cam.ac.uk/ucamfederation-idp2-metadata.xml

if your SP only identifies people from within the University, or of

 http://metadata.ukfederation.org.uk/ukfederation-metadata.xml

if it identifies people from other institutions in the UK federation. If they look correct, check that the metadata is being downloaded correctly (look in /var/run/shibboleth). If that looks OK, check the Shibboleth logs in /var/log/shibboleth/. Errors the IdP's metadata, for example a mismatch between the keys in the metadata and the keys the IdP is actually using, can also provoke these errors.

No attributes

Authentication seems to work, but absolutely no attributes are returned

Under Shib, attribute transfer is commonly handled separately from authentication. The latter tends to happen by HTTP redirect with all messages passing through the user's browser. The former often happens over a separately-established direct connection between the SP and the IdP.

Reasons for attribute release failing include:

• Most IdP's won't release any information to unregistered SPs. So any SP trying to interact with a non-Raven SP and not receiving any attributes should check if registration is required (see SP registration).
• The SP may be failing to establish a direct connection to the IdP, perhaps because of firewall rules. If this connection fails there is likely to be an entry in shibd.log relating to to the problem. Many but not all IdPs listen for incoming SP<->IdP connections on port 8443; this applies to Raven.
• The SP<->IdP connection is protected by mutually-authenticated SSL, using certificates identified or carried in the IdP and SP metadata. Mistakes in this setup (for example regenerating SP keys without updating the metadata held by the corresponding IdP) can prevent the SP<->IdP conenction from working. Again, if this is the case here is likely to be an entry in shibd.log relating to to the problem (see SSL, certificates and security with Shibboleth for more detail).

Looping between SP and IdP after setting cookieProps

After setting the 'cookieProps' attribute of the <Sessions> element to "; path=/; secure", attempts to authenticate end up with the browser looping endlessly between the SP and the IdP

Setting the 'cookieProps' attribute to "; path=/; secure" ensures that the cookie used to identify the user will only be returned in response to requests over secure (i.e. https) connections. However setting this without also ensuring that all access to the site use https can lead to authentication requests looping between the SP and the IdP. The problem is that authentication can complete over https, but when the user is redirected to the http URL they originally requested the cookie isn't supplied. This leads the SP to conclude that the user isn't authenticated and the loop is repeated.

To avoid this, always ensure that all http requests requiring authentication are first redirected to the corresponding https URL. This can either be done within the web server or the site it is serving, or by the SP using either the ShibRedirectToSSL Apache directive (ShibRedirectToSSL <portnumber>) or by setting the 'redirectToSSL' attribute of a <RequestMap>, <Host>, <HostRegex>, <Path>, <PathRegex> or <Query> element to the https port number within the shibboleth2.xml <RequestMapper> element. Note that you can't add this property to the <RequestMapper> itself - adding it doesn't casue an error but it doesn't work either. The https port number is commonly 443.

See also SSL, certificates and security with Shibboleth, and https://wiki.shibboleth.net/confluence/display/SHIB/RedirectLooping (the latter is actually for Shib 1 but is still relevant).

Starting shibd reports "Starting shibd listener failed to enter listen loop"

Whan (re-) starting shibd the message "Starting shibd listener failed to enter listen loop" is displayed as shibd doesn't start

At least one cause of this is that shibd is being started by an insufficiently privileged user. Typically shibd needs to be started as root.

Internal Server Error. Please contact the site administrator

Accessing a site results in a page saying "Internal Server Error. Please contact the site administrator."

This suggests that something went wrong and the SP software could not find the error page templates to report it better.

If combined with the message "could not process error template (session)" logged in .../var/log/httpd/native.log then it suggests that the SP could not find an <ApplicationDefaults> or <ApplicationOverride> entry that matches the 'applicationId' declared in the <Host> element for the relevant virtual host. Check the spelling of the 'applicationId' and 'id' attribute values.

'Error decoding Shibboleth SSO request' or 'No login context available'

Error messages mentioning 'Error decoding Shibboleth SSO request' or 'No login context available' can be cause by a variety of problems, but by far the easiest way to get them is to try to use the browser 'back' button to back up over a Shibboelth authentication. Because of the way the Shib server manages the authentication process this is never going to work. It should however be possible to go back to your desired resource and to try to login again.