<div dir="ltr">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 : <br><ul><li>Multiple SP and One IDP</li><li>Multiple IdP and One SP</li></ul><div>You have suggested to make multiple SP and write only one IDP, I think it's the better solution because it's more logical : there's only one user store. But the thing is we are only responsible for SP part and not IdP : Believe me when you work in big project, you get this weird and complicated situation. What's more is that a company deploy IdP part and the SP is done by our company.What's more the IdP company is our client and they already chosen the fact that they will create multiple IdP. So given all theses circonstances, the only solution that is left is Multiple IDP and One SP.  </div><div><br></div><div>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). </div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-17 15:57 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 15:16]:<br>
> - The project that I'm working for oblige me to write one SP for<br>
<span class="">> multiple websites with the fact that each website have it's own IdP. Why<br>
> one SP was chosen?:  The architect has chosen that because of SSO. Each IdP<br>
> has a personalized login page for the website and we can not afford that<br>
> someone see a login page of an other siteweb even if the user store is the<br>
> same. BUT when we are login in a website, we are then authenticated in all<br>
> websites (This is not a constraint of the solution but the<br>
> behavior wanted).<br>
<br>
</span>Commenting on other aspects of the above, at the risk of confusing you<br>
further -- this is getting ever more complicated and convoluted, not less:<br>
<br>
If you're now saying that the IDPs' login pages need to be changed<br>
depending on the vhost accessed at the SP, then yes: Then each vhost<br>
at the SP would need to become a logically seperate SP (using<br>
Overrides), each with its own entityID and its own Metadata. This is<br>
because the level policy applies to in SAML is the entityID, so the<br>
IDP would only be able to tell apart SPs with seperate entityIDs.<br>
<br>
Now, if you're saying there's only one user store (authentication<br>
source) shared by all the IDPs, and that the only difference between<br>
all those IDPs is their login page design, then you could well do all<br>
this with a single IDP installation:<br>
The Shibboleth IDP's login page can be branded based on the SP<br>
accessed. So instead of creating dozens (or whatever the number of<br>
virtual IDPs were talking about here) of IDPs you could have a<br>
customized login page for each org unit in a single IDP installation.<br>
<br>
Of course branding the IDP login page depending on the SP is<br>
semi-pointless, as the login page is only shown once as long as your<br>
browser has an SSO session with the IDP. I.e, starting with a fresh<br>
browser accessing <a href="http://foo.example.org" rel="noreferrer" target="_blank">foo.example.org</a> you might be promoted for login at<br>
<a href="http://idp.example.org" rel="noreferrer" target="_blank">idp.example.org</a> with a foo-specific design. But later accessing<br>
<a href="http://bar.example.org" rel="noreferrer" target="_blank">bar.example.org</a> will NOT prompt the same subject to authenticate at a<br>
bar-branded login page, instead you'd experience SSO and be logged in<br>
at the bar SP. (Which is what the subject wants, likely.)<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>