<div dir="ltr">Thanks for your valuable insights, Gentlemen. <br><br>What I am getting ( I might be wrong ) then.. there is none who actually made CAS app SLO participation properly work in Shibboleth IDP Production? </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 3, 2020 at 2:23 PM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/3/20, 2:20 PM, "users on behalf of Michael A Grady" <<a href="mailto:users-bounces@shibboleth.net" target="_blank">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:mgrady@unicon.net" target="_blank">mgrady@unicon.net</a>> wrote:<br>
<br>
> It doesn't appear to be back-channel only, it appears to in some cases pass a POST back thru the user's browser with a<br>
> logoutRequest parameter. But it also doesn't seem to be consistent. But at least in some cases, it appears to be<br>
> propagating the logout to participating CAS services thru such a POST thru the browser.<br>
<br>
Our mechanic for invoking propagation is always done that way to allow the UI to report the results, but what happens after that is protocol specific, and my understanding is that it's the server hitting an endpoint at the app and then tunneling a result back that signals success/failure.<br>
<br>
Marvin can correct me of course, but as I understood things, it was just what was informally defined for CAS.<br>
<br>
-- Scott<br>
<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Best,<br>Zico</div>