Shibboleth handler invoked at an unconfigured location
sabiretude at gmail.com
Tue May 17 12:30:16 EDT 2016
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
Thank you again, you helped me to realize something basic but easily
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
> 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.
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users