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.

Invalid assertion consumer service URL

When I try to authenticate I get an error page from Raven (or some other IdP) containing the text "Invalid assertion consumer service URL".

The metadata used to register an SP in the UCam or UK federation includes a list of the URLs (in one or more <AssertionConsumerService> elements) to which IdPs are allowed to return information. When an SP makes an authentication request it includes (typically in the 'shire' parameter) the URL to which it wants the results returned on this occasion. This message means that the URL in the request does not match any of the ones in the metadata. Despite the message being reported by the IdP, it reflects a problem on the SP. This message won't (shouldn't) appear for SP which are not registered since by definition there isn't any metadata about them.

SPs create assertion consumer service (ACS) URLs from information in the shibboleth2.xml file (the 'handlerURL' and 'handlerSSL' attributes of the <Sessions> element and the 'Location' attribute of the relevant <AssertionConsumerService> element), and from the details of the relavent virtual host. In the default configuration the SP uses the scheme (http: or https:) and host name of the virtual host handling the request and the values of the 'handlerURL' and 'Location' attributes to construct an ACS URL. In the default configuration, an authentication request using the SAML 1.0 Browser/POST profile triggered by access to

 http://www.example.cam.ac.uk/secure/

would be

 http://www.example.cam.ac.uk/Shibboleth.sso/SAML/POST

The "Invalid assertion consumer service URL" error message could 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. However the most common cause is accessing over http an SP that also supports https and which has registered https assertion consumer service URLs since the generated ACS URLs will be for http. There are several ways to avoid this:

• Set the 'handlerSSL' attribute of the <Sessions> element to "true". This will force all ACS URLs (and other internally-serviced URLs) to use the https scheme but continue to allow the site to be accessed over http.
• Force all access to the site to be over https. 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>, or <Path> element to "true" within the <RequestMapper> element of shibboleth2.xml.
• Disable http support completely.
• Disable https support and re-register your SP using http: ACS URLs.

No attributes

Authentication seems to work, but absolutely no attributes are returned

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

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.