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

[Nate Klingenstein]

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="https://idp.testshib.org/idp/shibboleth">
                  <SessionInitiator type="SAML2" acsByIndex="false" acsIndex="1" template="/etc/shibboleth/bindingTemplate.html"/>
                  <SessionInitiator type="Shib1" acsIndex="5"/>
            </SessionInitiator>

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 univie.ac.at> wrote:
> 
> * Peter Schober <peter.schober at univie.ac.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
>  (https://sp.testshib.org/Shibboleth.sso/DS)
>  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 shibboleth.net