<div dir="ltr">Hello again,<div><br></div><div>I want to start by thanking you for all your suggestion. Therefore, I didn't understand all the points that you have given but I could answer your question:</div><div><ul><li>The project that I'm working for oblige me to write one SP for multiple websites with the fact that each website have it's own IdP. Why one SP was chosen?:  The architect has chosen that because of SSO. Each IdP has a personalized login page for the website and we can not afford that someone see a login page of an other siteweb even if the user store is the same. BUT when we are login in a website, we are then authenticated in all websites (This is not a constraint of the solution but the behavior wanted).</li></ul><div>Now my knowledge let me think that we can not write all the previous behavior in the metadata. We need to write some codes or use an implementation that allow such things. Shibboleth was proposed because it seems that this behavior is allowed with the previous settings (each vhost is linked to an applicationID). But if you say that there's also a better and simple alternative, please just develop your idea by taking some example of configuration (write some pseudo configuration). </div><div><br></div><div>Anyway, I'm very grateful for your contribution </div></div><div><br></div><div>Reda</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-17 12:00 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 09:18]:<br>
<span class="">> So let's summarize our exchange to solve the problem :<br>
><br>
</span>>    - I need to build an SP that will secure multiple websites (each website<br>
<span class="">>    have it's own FQDN and it's own IDP). This means that if I authenticate<br>
>    into one of my websites, I won't do it again for another one until I log<br>
>    out.<br>
<br>
</span>Each web site having "its own IDP" could mean that each website can<br>
only be accessed from one specific IDP, and access would be denied<br>
when trying to access it from any other IDP (i.e., after having<br>
established a session with another IDP, e.g. from accessing a<br>
different vhost on that server first).<br>
If that's the intended meaning, and the use of tying vhost to IDP<br>
merely serves the purpose of avoid IDP Discovery, then you can do that<br>
with the entityID content setting on each vhost (avoiding discovery)<br>
*plus* by adding access control rules on each vhost (avoiding access<br>
from one IDP to a vhost that defaults to another IDP).<br>
You'd write those access control rules based on SAML Attributes, or,<br>
if all else fails, by using the IDP's entityID itself in an ACL rule.<br>
<br>
Or it could mean that each vhost defaults to a specific IDP but that<br>
accessing it from other IDPs is fine, too.  Then the steps are the<br>
same as above, only the access control rules would be different (not<br>
limiting each vhost to one IDP, but limiting the resource to<br>
authorized subjects, as you'd usually do).<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>