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.