Shibboleth handler invoked at an unconfigured location

[Peter Schober]

* reda sabir <sabiretude at gmail.com> [2016-05-17 17:06]:
> I can assure that we are now converging to the right understanding of the
> problem. As you have commented, there's two possibilities for the project :
> 
>    - Multiple SP and One IDP
>    - Multiple IdP and One SP

Plus the obvious one (it's really just one SP and one IDP, as it turns
out), but that doesn't match your "requirements" to make this appear
much more complicated. :-\

> That's why we should stay with multiple vhost with one SP (the
> entityID is never overrided, only SSO part and metadata of the idp
> is changed).

There won't be much SSO'ing, though, even if you allow any subject to
use any IDP to access any of the vhosts: When all IDPs are separate
and each vhost at the SP defaults to a specific, different IDP, the
subject would be sent to different IDPs all the time (by design, since
you create one vhost per one IDP, per your earlier description).
And at each IDP she wouldn't have an established SSO session with that
IDP.
Neither will there be session re-use on the SP side, since session
cookies are by default scoped to the vhost and therfore will not
overlap in your setup.

Anyway, looks like you now know what you need to do? Add metadata
about IDPs to the SP, add content setting for IDP pre-selection, done.
-peter