Integrating CAS into logout/SLO

[Cantor, Scott]

On 6/17/15, 12:10 PM, "dev on behalf of Marvin Addison" <dev-bounces at shibboleth.net on behalf of marvin.addison at gmail.com> wrote:



>I'm keen on completing IDP-645 <https://issues.shibboleth.net/jira/browse/IDP-645> prior to
> 3.2.0 and I've been doing some recon to see what's required. The CAS-specific pieces are straightforward, but I'm thinking more about integration with the IdP logout process and SLO specifically. If I squint, I believe I can see how the SLO piece is intended
> to be protocol agnostic: implement a logoutprop/X flow for protocol X and given a proper selector function it will be selected and executed for each suitable SPSession bound to the IdPSession. Is that right? Anything else notable to be aware of?

Yes, and I apologize given that I owed you some documentation on that, which I said I would get done, and haven't. That's an accurate one sentence summary.

The goal was to decouple the initial logout initiation flow from the webflows that would run for each SPSession in the IdPSession, because webflow is (or seems to me) highly synchronous and linear, and the front-channel logout design has to be something that runs in parallel from frames (so client-driven) to be practical.

My webflow-fu wasn't sufficient to envision how that could work with a single webflow.

>It looks like there are two endpoints for logout depending on what is desired:
>1. /profile/Logout - ends IdPSession

That's the proprietary "just do it" endpoint. The others are SAML Logout profile endpoints.

>2. /profile/PropagateLogout - sends SLO message to each IdPSession bound to the IdPSession

SPSession you mean, but yes.

>What's the relationship between the two? It looks like logout+SLO requires two separate requests to each endpoint, PropagateLogout followed by Logout (order seems to matter). Is that correct? Don't see any problems thus far.

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.

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

So it's basically the other way around, Logout followed by PropagateLogout.

>I was hoping that logoutprop/X flows could optionally interact with the browser so we could do front-channel messaging.

That's intended to happen in the "render a view" step above. The idea was to simplify the LogoutPropagation subflows, but I would have to think about the statement in the javadoc and whether that actually is true based on how I expected the front-channel propagation to work. That statement may no longer be true, it just might have started out that way in my mind.

>I vaguely recall Scott discussing that at some point in the past (IFRAMEs and such), which seems like a front-channel construct, so I'm confused about what sorts of things logout propagation flows can do.

I am unsure, we will have to revisit it. Also 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.

>In terms of work and scheduling, I believe my CAS-specific issue should depend on the larger SLO work. Is IDP-224 the right issue for that?

We could, it should be renamed in that case. That's where all my brain dumps were left.

-- Scott