Integrating CAS into logout/SLO

[Cantor, Scott]

On 6/17/15, 2:26 PM, "dev on behalf of Marvin Addison" <dev-bounces at shibboleth.net on behalf of marvin.addison at gmail.com> wrote:
>
>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.

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

It isn't suported now anymore than it's supprted with SAML, I haven't built (nor even thought deeply about how to build) that master view. The view today is much simpler and just does a bit of a dump of the SPSessions it sees. That's the view we have to dramatically enhance.

The intent is *not* that you have to do that in a CAS-specific mannger, but that we collectively get that view built and have it getting the logoutprop flow invoked. The CAS/SAML/etc. part is just the prop subflow. I hope.

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

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

The way I try and describe it is logout initiation vs. logout propagation. There's a protocol to initiate logout (SAML, CAS, proprietary), each being its own web flow. Then we have subflows to propagate logout by each supported SPSession type, called by the propagation flow.

The idea was to decouple those two pieces so that any initiation protocol can end up invoking a mix of the propagation subflows out of a view it controls, giving us the behavior we want: SAML logout of the IDP session followed by CAS/SAML/etc. logouts to SPs.

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

Supporting that in the various initiating flows is part of finishing the work, yes. But I didn't want to do it in the propagation part.

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

Understood.

>I'll defer to you; just need to know a Jira number to create a dependency in IDP-645.

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

We can talk through this either with agenda time Friday, or two weeks following if we have something else to fill the agenda.

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

-- Scott