Shibboleth handler invoked at an unconfigured location

[Peter Schober]

* reda sabir <sabiretude at gmail.com> [2016-05-17 15:16]:
> - The project that I'm working for oblige me to write one SP for
> multiple websites with the fact that each website have it's own IdP. Why
> one SP was chosen?:  The architect has chosen that because of SSO. Each IdP
> has a personalized login page for the website and we can not afford that
> someone see a login page of an other siteweb even if the user store is the
> same. BUT when we are login in a website, we are then authenticated in all
> websites (This is not a constraint of the solution but the
> behavior wanted).

Commenting on other aspects of the above, at the risk of confusing you
further -- this is getting ever more complicated and convoluted, not less:

If you're now saying that the IDPs' login pages need to be changed
depending on the vhost accessed at the SP, then yes: Then each vhost
at the SP would need to become a logically seperate SP (using
Overrides), each with its own entityID and its own Metadata. This is
because the level policy applies to in SAML is the entityID, so the
IDP would only be able to tell apart SPs with seperate entityIDs.

Now, if you're saying there's only one user store (authentication
source) shared by all the IDPs, and that the only difference between
all those IDPs is their login page design, then you could well do all
this with a single IDP installation:
The Shibboleth IDP's login page can be branded based on the SP
accessed. So instead of creating dozens (or whatever the number of
virtual IDPs were talking about here) of IDPs you could have a
customized login page for each org unit in a single IDP installation.

Of course branding the IDP login page depending on the SP is
semi-pointless, as the login page is only shown once as long as your
browser has an SSO session with the IDP. I.e, starting with a fresh
browser accessing foo.example.org you might be promoted for login at
idp.example.org with a foo-specific design. But later accessing
bar.example.org will NOT prompt the same subject to authenticate at a
bar-branded login page, instead you'd experience SSO and be logged in
at the bar SP. (Which is what the subject wants, likely.)
-peter