Shibboleth handler invoked at an unconfigured location

[reda sabir]

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.
We can say then it's impossible to have SSO with one SP and multiple FQDN.
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. Can we do this in Shibboleth? 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?

Thank you again, you helped me to realize something basic but easily
forgotten

2016-05-17 17:37 GMT+02:00 Peter Schober <peter.schober at univie.ac.at>:

> * 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
> --
> 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/20160517/d03d108b/attachment.html>