<div dir="ltr">Hello,<br><br>I found  a more simple solution:<div> In some implementation of SAML, we can set the scope of cookies. For instance, I can try to make all websites have a common domain name like <a href="http://company.com">company.com</a> and so the websites will be: <a href="http://site1.company.com">site1.company.com</a>, <a href="http://site2.company.com">site2.company.com</a> and so on. This will allow me to share the cookie between the websites by setting the cookie scope to 2 or set the cookie domain <a href="http://company.com">company.com</a>. Can we do this in Shibboleth SP. I've found this in the documentation:</div><div><<<span style="color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px">The SP uses a setting called </span><code style="color:rgb(51,51,51);font-size:14px;line-height:20px"><a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions" style="color:rgb(50,96,186);text-decoration:none">cookieProps</a></code><font color="#333333" face="Arial, sans-serif"><span style="font-size:14px;line-height:20px"> that controls the properties used in the creation of all of the cookies it sets. In particular, whether the cookie is limited to https requests, the domain and path, and other properties such as the HttpOnly flag can be set by the deployer and so will vary between sites. However, by default in the latest version, the cookies are scoped to the fully-qualified host, with a path of "/" (the whole host), and the HttpOnly flag set. They are not marked "secure" by default due to the prevalence of testing done without https, but this is a recommended change.>></span></font><br><font color="#333333" face="Arial, sans-serif"><span style="font-size:14px;line-height:20px">However, I didn't found how we can modify the scope of Cookie.</span></font></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px"><br></span></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px">Reda</span></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-17 19:40 GMT+02:00 Peter Schober <span dir="ltr"><<a href="mailto:peter.schober@univie.ac.at" target="_blank">peter.schober@univie.ac.at</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* reda sabir <<a href="mailto:sabiretude@gmail.com">sabiretude@gmail.com</a>> [2016-05-17 18:30]:<br>
<span class="">> And now I understand, me,  why you have difficulties to accept the solution<br>
> of One SP with Multiple IDP. I was so engaged on the technical part<br>
> (Shibolleth) that I didn't realize that it's not possible.<br>
> As you have said we can't have SSO for the simple reason: The session<br>
> cookies can't be sent to another vhost  because they have different FQDN<br>
> and at the end, the only thing that associate me the user with a session in<br>
> Server is Cookies. So I'm in trouble.<br>
<br>
</span>If the vhosts share a common DNS domain you could try to forgo<br>
SAML-based SSO (involving a set of IDPs) and instead use a shared<br>
domain cookie across all services. (Either the Shibboleth SP's session<br>
cookie or an application cookie initially bootstrapped from one Shib<br>
SP session and shared across all vhosts).<br>
<span class=""><br>
> We can say then it's impossible to have SSO with one SP and multiple FQDN.<br>
<br>
</span>Only if you mandate that each vhost can only be accessed from a<br>
different IDP, even though you want all vhosts to be accessible from<br>
all IDPs. (That's a contradiction to some degree.)<br>
<span class=""><br>
> So a solution for my case could be to make some proxy where I could send a<br>
> cookie when I'm authenticated and if not it will resend me to the right<br>
> IDP.<br>
<br>
</span>While you could have a common authentication system for all IDPs<br>
(basically implementing another SSO system to protect access to the<br>
IDPs) that would essentially cause all IDPs appear as one system, with<br>
one login screen (unless you integrate IDP-specific branding into that<br>
abstracted authentication system).<br>
<span class=""><br>
> Can we do this in Shibboleth?<br>
<br>
</span>It's always about the details.<br>
<span class=""><br>
> I mean I know there's IDP Discovery but can it work by taking into<br>
> account parameters (in header or in request GET or POST). For<br>
> example, if I pass <a href="http://site1.com" rel="noreferrer" target="_blank">site1.com</a> it will redirect me to <a href="http://idp.site1.com" rel="noreferrer" target="_blank">idp.site1.com</a><br>
> and so on? Or if I pass the <a href="http://idp.site1.com" rel="noreferrer" target="_blank">idp.site1.com</a> it will send me to it?<br>
<br>
</span>Sorry, I can't wrap my head around this now.<br>
<div class="HOEnZb"><div class="h5">-peter<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div></div>