Allowing the Metadata to determine end-points

[Cantor, Scott]

On 1/27/16, 10:37 AM, "users on behalf of Antony den Dulk" <users-bounces at shibboleth.net on behalf of antony at selestiasolutions.com> wrote:


>
> 
>The IdP is not using the metadata in this way, it does not verify the URI that comes in a signed authentication request.

Typically such an IdP would simply use the endpoint the SP specifies. That's one of the purposes of signing the request.

There would be little point to signing the request if the URL weren't specified in fact, unless some other relevant content were being sent. The basic skeleton of an AuthnRequest doesn't have much besides the URL in fact.

The other weird thing is, why would the IdP *need* the SP not to say anything? If it was going to simply use the metadata alone, then it wouldn't care what the SP said. Just doesn't really make a lot of sense. And if the SP specified exactly what the metadata contained, why wouldn't that work?

Basically, you'd have to write deliberately broken code to make this fail. It's not going to be an accidental bug of omission.

Also, throwing around statements about what SAML supports is a bit silly given that it's obviously required of an *IdP* to support both value and index, in the exact section they're quoting. Typically SAML compliance is more about the ability to understand a message than generate one, as the latter is situational.

>So even using by Index may break the system. Thanks for sending me the link in your other post.
> 

Using an index in and of itself is fine, but if you were to specify at runtime an index (via acsIndex) that didn't have cookie-compatibility with the eventual resource, then you'd loop. So the normal way is "let the SP figure out the URL that will work", which allows it to derive http for an http resource, that kind of thing.

A simple deployment isn't going to see much difference, but a multi-vhost situation can easily get screwed up.

-- Scott