Specify the SingleSignOnService HTTP-Redirect URL to use?

[Terry Fleury]

Thanks Tom and Scott for the info.

In the InCommon-metadata.xml file, I found two IdPs with multiple 
HTTP-Redirect entries, but one of those listed the same URL twice, so 
that one is clearly a bug. I tried to "change the names to protect the 
innocent", but you can easily search the metadata for the other IdP with 
multiple HTTP-Redirects.

Since I now know that the standard should have only one endpoint for the 
HTTP-Redirect, I think I'll end my inquiry and let the higher-ups figure 
out how to handle the metadata issue.

Thanks for the help!

Terry Fleury
tfleury at illinois.edu



On 2/7/2013 11:35 AM, Cantor, Scott wrote:
>> Our SP needs to connect to an IdP which has multiple SingleSignOnService
>> endpoints of type "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect",
>> and we need to connect to the second one configured in the metadata.
> There's no support in the standard for that, so it isn't something we do.
>
>> By default, site1.example.com is utilized since it appears first in the
>> metadata. The only way I could figure out to use site2.example.com was
>> to delete site1.example.com from the metadata. This is not a viable
>> solution for the InCommon metadata file.
> I didn't think InCommon allowed multiple endpoints of that type with the same binding. If they do, I'm not sure they intended to, I would guess not, which I think Tom confirmed.
>
>> So my questions are:
>>
>> (1) Is it possible for the SP to specify to connect to
>> site2.example.com, either programatically (e.g., by using
>> SessionInitiator creation parameters) or via configuration?
>> (2) If not (1), would this be something that could easily be
>> implemented? If so, I would be happy to submit a feature request.
> It isn't supported, and I would be hesitant to based on the behavior one would expect in the standard. The normal way this would be done in SAML would be if the endpoint were indexed, but that element isn't defined that way.
>
> It's not hard to code something, but the thing is that it's considered a really bad thing to have URLs bound into the configuration, and we did a lot of work to end that practice.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>