Shibboleth handler invoked at an unconfigured location

[Peter Schober]

* reda sabir <sabiretude at gmail.com> [2016-05-17 09:18]:
> So let's summarize our exchange to solve the problem :
> 
>    - I need to build an SP that will secure multiple websites (each website
>    have it's own FQDN and it's own IDP). This means that if I authenticate
>    into one of my websites, I won't do it again for another one until I log
>    out.

Each web site having "its own IDP" could mean that each website can
only be accessed from one specific IDP, and access would be denied
when trying to access it from any other IDP (i.e., after having
established a session with another IDP, e.g. from accessing a
different vhost on that server first).
If that's the intended meaning, and the use of tying vhost to IDP
merely serves the purpose of avoid IDP Discovery, then you can do that
with the entityID content setting on each vhost (avoiding discovery)
*plus* by adding access control rules on each vhost (avoiding access
from one IDP to a vhost that defaults to another IDP).
You'd write those access control rules based on SAML Attributes, or,
if all else fails, by using the IDP's entityID itself in an ACL rule.

Or it could mean that each vhost defaults to a specific IDP but that
accessing it from other IDPs is fine, too.  Then the steps are the
same as above, only the access control rules would be different (not
limiting each vhost to one IDP, but limiting the resource to
authorized subjects, as you'd usually do).
-peter