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".

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 includes (typically in the 'shire' parameter) the ACS 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 those 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 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 virtual host handling the current request. In the default configuration, the SP uses the scheme (http: or https:) and host name of the virtual host 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 include this as an ACS URL:

 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. 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).

However the most common cause is accessing an SP over http that also supports https and which has registered https assertion consumer service URLs. In this case the ACS URL generated will be for http and these won't match those in the metadata. There are several ways to avoid this:

• Force all access to the site to be over https. This is probably the best solution since it also provides better secutity (see SSL, certificates and security with Shibboleth). 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 the https port number within the shibboleth2.xml <RequestMapper> element. The https port number is commonly 443.
• 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 content of the site to be accessed over http.
• Register both http and https URLs in the SP metadata. This can be most easily achieved by adding https="true" http="true" attributes to the <Handler type="MetadataGenerator"> entry in shibboleth2.xml and them re-generating the Metadata.
• Disable http support completely.
• Disable https support and re-register your SP using just 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

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 coresponding 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>, or <Path> element to the https port number within the shibboleth2.xml <RequestMapper> element. The https port number is commonly 443.

See also https://spaces.internet2.edu/display/SHIB/RedirectLooping (actually for Shib 1 but 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.