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