Shibboleth handler invoked at an unconfigured location

[Peter Schober]

* reda sabir <sabiretude at gmail.com> [2016-05-17 18:30]:
> And now I understand, me,  why you have difficulties to accept the solution
> of One SP with Multiple IDP. I was so engaged on the technical part
> (Shibolleth) that I didn't realize that it's not possible.
> As you have said we can't have SSO for the simple reason: The session
> cookies can't be sent to another vhost  because they have different FQDN
> and at the end, the only thing that associate me the user with a session in
> Server is Cookies. So I'm in trouble.

If the vhosts share a common DNS domain you could try to forgo
SAML-based SSO (involving a set of IDPs) and instead use a shared
domain cookie across all services. (Either the Shibboleth SP's session
cookie or an application cookie initially bootstrapped from one Shib
SP session and shared across all vhosts).

> We can say then it's impossible to have SSO with one SP and multiple FQDN.

Only if you mandate that each vhost can only be accessed from a
different IDP, even though you want all vhosts to be accessible from
all IDPs. (That's a contradiction to some degree.)

> So a solution for my case could be to make some proxy where I could send a
> cookie when I'm authenticated and if not it will resend me to the right
> IDP.

While you could have a common authentication system for all IDPs
(basically implementing another SSO system to protect access to the
IDPs) that would essentially cause all IDPs appear as one system, with
one login screen (unless you integrate IDP-specific branding into that
abstracted authentication system).

> Can we do this in Shibboleth?

It's always about the details.

> I mean I know there's IDP Discovery but can it work by taking into
> account parameters (in header or in request GET or POST). For
> example, if I pass site1.com it will redirect me to idp.site1.com
> and so on? Or if I pass the idp.site1.com it will send me to it?

Sorry, I can't wrap my head around this now.
-peter