DS: The return URL could not be verified for Service Provider

jehan procaccia jehan.procaccia at it-sudparis.eu
Sun Nov 20 18:18:24 GMT 2011


Le 18/11/2011 23:00, Cantor, Scott a écrit :
> On 11/18/11 4:34 PM, "jehan procaccia"<jehan.procaccia at it-sudparis.eu>
> wrote:
>
>> hello,
>>
>> when I try to login I immediatly end up on the DS responding on the
>> browser:
>>
>> Error: Invalid Query
>> The return URL 'https://www-public.it-sudparis.eu/Shibboleth.sso/DS'
>> could not be verified
>> for Service Provider 'https://www-public.it-sudparis.eu/shibboleth'.
> Your SP's metadata at the DS doesn't include the necessary
> DiscoveryResponse extension endpoint. Allowing free access to the DS makes
> it a cookie phishing service. Some people think that's fine, and some
> don't happen to agree with them. Regardless, it's a DS setting as to
> whether to allow it without checking the metadata.
You're right
thanks to that post :
https://lists.internet2.edu/sympa/arc/shibboleth-users/2010-06/msg00180.html

I realized that I did the same, I had added a sessionInitiator in my SP 
shibboleth2.xml to support differents ("chain") DS listing differents IDPs,
without updating accordingly  my internal federation metadatas !
added shibboleth2.xml:
<SessionInitiator type="Chaining" Location="/DS" id="DS" 
isDefault="true" relayState="cookie">

which ended in a SP metadata updated with

<md:SPSSODescriptor 
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol 
urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:1.0:protocol">
<md:Extensions>
<init:RequestInitiator 
xmlns:init="urn:oasis:names:tc:SAML:profiles:SSO:request-init" 
Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init" 
Location="https://www-public.it-sudparis.eu/Shibboleth.sso/Login"/>
<idpdisc:DiscoveryResponse 
xmlns:idpdisc="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" 
Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" 
Location="https://www-public.it-sudparis.eu/Shibboleth.sso/Login" 
index="1"/>
<init:RequestInitiator 
xmlns:init="urn:oasis:names:tc:SAML:profiles:SSO:request-init" 
Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init" 
Location="https://www-public.it-sudparis.eu/Shibboleth.sso/WAYFMT"/>
<init:RequestInitiator 
xmlns:init="urn:oasis:names:tc:SAML:profiles:SSO:request-init" 
Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init" 
Location="https://www-public.it-sudparis.eu/Shibboleth.sso/DS"/>
<idpdisc:DiscoveryResponse 
xmlns:idpdisc="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" 
Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" 
Location="https://www-public.it-sudparis.eu/Shibboleth.sso/DS" index="2"/>

Now , all my SP application works fine with their repective IDP listings .

Thanks .

PS: for the record, other docs that helped me:
https://spaces.internet2.edu/display/InCCollaborate/Shibboleth+Discovery+Config
https://wiki.shibboleth.net/confluence/display/SHIB2/DSTroubleshootingCommonErrors
https://wiki.shibboleth.net/confluence/display/SHIB2/DSAddMetadata


More information about the users mailing list