Dynamic (or Relative) URL for both IdP and SP

[Kirill]

Scott,

Thank you for your reply.

> Top of mind is stop playing these games with URLs. I have no idea why you
think it's necessary for the IdP to live at different virtual hosts, but
that's just creating problems.

I would like to avoid these games more than anybody else, but as many here,
we are left no choice.

> unless you supply different metadata based on the vhost. The Shibboleth
SP certainly can handle that, but it's hardly productive work.

Can the same thing be done for the IdP (ver. 3.1.2)? I mean supplying (or
rather choosing) different SP's metadata depending on the host name of the
access URL? If yes, could somebody give me some pointers on where to look
at?

--

By the way, I plan to use multiple IdP's entityIDs and use IdP Discovery to
make the correct selection of the IdP on the SP side.

Thanks!




On Tue, Feb 2, 2016 at 12:09 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > Option 1. Relative urls for the endpoints in metadata for both IdP and
> SP.
> >
> > Is this possible / allowed at all from SAML perspective? Are there any
> issues I
> > need to worry about?
>
> Not allowed and not supported.
>
> > Option 2. Hack into SP's and IdP's assertions creation logic in order to
> set
> > correct URL for HTTP-POST bindings (we only use post bindings)
>
> It's the SP implementation responsible for properly expressing the URL it
> needs used, and the IdP should simply enforce that via metadata. Your
> problem is a broken SP, or a broken configuration of an SP.
>
> A Shibboleth SP, certainly, will do the right thing if the web server is
> properly configured.
>
> > Any ideas how I can solve this problem?
>
> Top of mind is stop playing these games with URLs. I have no idea why you
> think it's necessary for the IdP to live at different virtual hosts, but
> that's just creating problems. You cannot, with one entityID, dictate which
> SSO endpoint an SP will use unless you supply different metadata based on
> the vhost. The Shibboleth SP certainly can handle that, but it's hardly
> productive work.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160204/9d2fd70c/attachment.html>