<div dir="ltr">thank you Peter ,<div>what about the SP session , it's keeped even if the IDP ask always the CAS .</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-15 15:34 GMT+00: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">* samir el otmani <<a href="mailto:elotmani.samir@gmail.com">elotmani.samir@gmail.com</a>> [2015-01-15 16:17]:<br>
> I mean by unique session : for example a *user1 *authenticate successfully<br>
> , after that an other *user2 *try to authenticate (with same 'Principal' of<br>
> the *user1*) , the session for *user1 *will be inactive , so user1 must<br>
<span class="">> authenticate again.<br>
> which means authentication will be granted for only one session ,and my<br>
> CAS server already support this use case and i want to dispatch it to the<br>
> IDP and SP sessions.<br>
<br>
</span>If you disable the IDP SSO session like I described, the IDP SSO<br>
session is out of the equasion. So however you think you can have SSO<br>
sometimes and forced re-authentication some other time (with the same<br>
principal!), it is not a Shibboleth issue anymore. So you're done.<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><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><i><font color="#0b5394" face="verdana, sans-serif"><b>EL OTMANI Samir</b></font></i><div><i><font color="#0b5394" face="verdana, sans-serif"><b>Ingénieur d'Etat en Génie Informatique </b></font></i></div><div><i><font color="#0b5394" face="verdana, sans-serif"><b>Tel:+212 699 041 864</b></font></i></div></div></div>
</div>