Shibboleth Idp does not persist URL hash fragments across a login redirect.

Nate Klingenstein ndk at
Wed Apr 13 12:15:57 EDT 2016

It is indeed basically a relic of configuration from the beginning of the universe.

There is an endpoint that is similar to the /Login default endpoint at /TestShib, still full of cruft for other historical reasons.

            <SessionInitiator type="Chaining" Location="/TestShib" isDefault="true" id="testshib-idp"
                  relayState="cookie" entityID="">
                  <SessionInitiator type="SAML2" acsByIndex="false" acsIndex="1" template="/etc/shibboleth/bindingTemplate.html"/>
                  <SessionInitiator type="Shib1" acsIndex="5"/>

You could probably use this.  I’ve changed the metadata to remove the DiscoveryService DS element and added a init:RequestInitiator TestShib element.

Thanks for reporting this.

> On Apr 13, 2016, at 09:57, Peter Schober <peter.schober at> wrote:
> * Peter Schober <peter.schober at> [2016-04-13 15:00]:
>> If the Testshib SP had a RequestInitiator endpoint configured
>> (e.g. /Shibboleth.sso/Login)
> Note that the Testshib SP publishes a DiscoveryReponse/@Location
> endpoint in the testshib-providers.xml that's not available:
>  shibsp::ConfigurationException at
>  (
>  Shibboleth handler invoked at an unconfigured location.
> That must be a artifact from an software earlier upgrade, combined
> with old configuration, I think.
> Could someone maybe fix that and add a RequestInitiator endpoint, too?
> Thanks,
> -peter
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at

More information about the users mailing list