<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">There's intended to be one view, managed by the master logout flow, not the logoutprop flow. That's the origin of the statement that the logoutprop subflows don't interact. What I was thinking (which I recalled in the car) was not that the subflows couldn't have a front-channel component, but that they literally wouldn't interact with the user in the sense of needing input. They would be rendering invisible in the iframes, so they may render their own views, but they oughtn't to expect them to be seen. They're programmatic basically.<br></blockquote><div><br></div><div>That indeed reconciles the javadoc comment about no user interaction.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The part that kicks off the whole sequence of events in each case is protocol specific. I expect the view that is rendered in each case to be substantially similar (if you look now, the SAML front-channel flows and the one at /profile/Logout are similar).<br></blockquote><div><br></div><div>I have been envisioning a CAS-specific logout flow at /profiles/cas/logout, but now I'm fairly certain I don't need one. Logout feels like it ought to apply to the IdP session as a whole and be protocol agnostic, and your proposed design would be consistent with that afaict. So instead of a top-level CAS logout flow, I am planning on a CAS-specific logout propagation subflow that fires when instances of CASSPSession are found in the IdPSession.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The way I try and describe it is logout initiation vs. logout propagation.</blockquote><div><br></div><div>That distinction was clear from the code and seems natural besides, especially for decoupling the protocol-specific bits.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'll rename the existing issue and get subtasks created for my stuff at least.<br></blockquote><div><br></div><div>Sounds good.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We can talk through this either with agenda time Friday<br></blockquote><div><br></div><div>I would like to discuss Friday at a high level with respect to planning and execution.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As always, I'm hampered by me total inability to diagram things to explain them, but we might want to whiteboard something electronically.<br></blockquote><div><br></div><div>Actually, I think the code and our discussion has painted a pretty clear picture of the high-level design, but I can imagine some details may merit further discussion. Agree drawings could be helpful.</div><div><br></div><div>M</div><div><br></div></div></div>