<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">the front-channel logout design has to be something that runs in parallel from frames (so client-driven) to be practical.<br></blockquote><div><br></div><div>Pretty sure that's the bit I was recalling from past discussion. That suggests to me that there could be a one-to-many relationship between the logoutprop views and SPSessions. That would accommodate what I want with CAS SLO where a collection of IFRAMEs, one per SP session, sends a POST message in parallel to all CAS services accessed during an SSO session. If that's intended to be a supported case, I don't see how to do it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You start with a logout flow that corresponds to some kind of message/profile. SAML is one, the simple front-channel redirect is another, CAS may be a third.<br></blockquote><div><br></div><div>I assumed the PropagateLogout process would apply to all, but now I'm not certain since you distinguished between SAML and "simple front-channel redirect" as distinct profiles.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That flow internally is assumed to be rendering a view that will invoke the PropagateLogout flow for each SPSession it has to dispose of (which is explicitly not done right now since I didn't implement logout propagation).<br></blockquote><div><br></div><div>Assuming PropagateLogout applies to front-channel processes, it would be nice to support a way to render a single view that handles multiple SPSessions. Again, I don't see a way to do this at present since it looks like views to SPSessions are 1:1.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">it bears noting that I have no actual experience trying to build the front-channel view for all this, so I was mostly designing in a vaccuum at the time and it wasn't work I completed for the release.<br></blockquote><div><br></div><div>I'm very interested in collaborating on this; if nothing else shimming the CAS stuff into whatever you come up with for SAML and testing in our dev environment. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>Is IDP-224 the right issue for that?<br>
<br>
We could, it should be renamed in that case. That's where all my brain dumps were left.<br></blockquote><div><br></div><div>I'll defer to you; just need to know a Jira number to create a dependency in IDP-645.</div><div><br></div><div>M<a href="mailto:dev-unsubscribe@shibboleth.net" target="_blank"></a><br>
</div><div><br></div></div></div>