Integrating CAS into logout/SLO
Marvin Addison
marvin.addison at gmail.com
Wed Jun 17 14:26:10 EDT 2015
>
> the front-channel logout design has to be something that runs in parallel
> from frames (so client-driven) to be practical.
>
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.
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.
>
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.
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).
>
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.
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.
>
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.
>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.
>
I'll defer to you; just need to know a Jira number to create a dependency
in IDP-645.
M <dev-unsubscribe at shibboleth.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150617/2622ee20/attachment.html>
More information about the dev
mailing list