Integrating CAS into logout/SLO

[Marvin Addison]

>
> 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.
>

That indeed reconciles the javadoc comment about no user interaction.

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).
>

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.

The way I try and describe it is logout initiation vs. logout propagation.


That distinction was clear from the code and seems natural besides,
especially for decoupling the protocol-specific bits.

I'll rename the existing issue and get subtasks created for my stuff at
> least.
>

Sounds good.

We can talk through this either with agenda time Friday
>

I would like to discuss Friday at a high level with respect to planning and
execution.

As always, I'm hampered by me total inability to diagram things to explain
> them, but we might want to whiteboard something electronically.
>

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.

M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150617/61fa3dbc/attachment.html>